[cddlm] Component Model discussion points

[Stuart Schaefer]

Over the past week, several questions were asked about the Component
Model.  They will be documented here and my response summarized for the
team and any further questions on how to resolve them.

 

1) Component Model tags as elements or attributes - how to resolve
inheritance issues

            

Using the CM definition of tags for elements such as <cmp:delegate> or
control flow elements, there is the possibility for complex behavior.  A
control flow element such as <cmp:sequence> can be multiply defined.  As
CDL elements are property lists, it is unclear whether multiply defined
elements are allowed.  XML allows such behavior and the CDL
specification does not explicitly prevent it.

 

There can be three possible types of behavior of inheritance when
multiple properties of the same name are specified in a single list.

(1) disallow multiple occurence.

(2) batch override

(3) streaming override

 

The CDL specification defines inheritance as a batch override process
where the nodes of a new list will overwrite the nodes of the original
list.  This is the only behavior that is feasible.

 

It was thought that by defining the CM elements as attributes, this
problem would be solved.  That is not the case, as CDL defines a similar
override process for attribute inheritance.

 

2) Delegate and inheritance's impact thereon

 

The current definition of the <cmp:delegate> element does not allow any
process of inheritance to change the delegation behavior of a node.  If
a node is a delegate, it cannot be "turned off" through any means.  It
was posited that allowing a Boolean value for the delegate element would
allow delegation to be turned on and off.

 

>From an inheritance perspective, I am concerned that people would
attempt to "turn on" or "turn off" delegation.  This would require that
all components be made to support both compound and primitive operations
(in SmartFrog speak).  Otherwise, we can "RECOMMEND" the use of the
value, such that implementers not "turn on" delegation unless they know
that a component supports such methods.

 

In our weekly meeting we proposed to leave the current behavior as it
stands, and discuss this topic for potential change in the next version
of the specification.  We will solicit usage cases for this behavior.

 

3) CMP switch element

 

Concern was expressed regarding the value of the <cmp:switch> element
and its potential for creating spaghetti control flow.  If flow control
is allowed to arbitrarily violate scopes of control flow, then
undetermined behavior will result.

 

I will be updating the component model to clarify the scoping behavior
of control flow elements to describe how this is not the case.  This
does not change the concern over the utility of the element.  It may be
complex to implement, with unknown value.

 

4) Event sequencing

 

There is concern that event registration is only done at the producer
side of the event model.  The consumer or target of the event cannot
register for the event.  I believe that this is merely a situation of
the semantics of the CDL element chosen to represent events.  Rather
than declaring a component can send events, and that another component
will register for that event, the CM defines in one construct this
process in addition to ordering restricition semantics.

 

The current definition sacrifices completeness for compactness and
simplicity.  The primary issue is resolution of synchronization
conditions at the consumer side.  It is possible that a consumer of an
event is within some scope of control flow, thus must ensure that it
both obeys control flow and the semantic of the event.

 

There is also concern of inheriting these event registrations, though it
is unknown what effect this will have.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/cddlm-wg/attachments/20050609/8ec00c6f/attachment.htm