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

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. 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.