RE: Proposal for Simplifications to the Component Model

Thank you for your comment - we tracked this as a Last Call comment LC105 [1].  The Working Group accepted only part of your proposal: adding the constraint that top-level components must be unique, and adding a parent property to nested components.
 
If we don't hear otherwise within two weeks, we will assume this satisfies your concern.
 
[1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC105


> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] 
> On Behalf Of Arthur Ryman
> Sent: Thursday, January 27, 2005 3:13 AM
> To: www-ws-desc@w3.org
> Subject: Proposal for Simplifications to the Component Model
> 
> As I mentioned in an earlier note [1], I've hit problems trying to 
> formally specify some aspects of the component model. These are 
> related to the interactions between interface inheritance, component
> equivalence, and extension elements. I'd like to propose some 
> simplifications here so I can move forward. 
>
> 1. The spec has the notion of component equivalence. This concept 
> was introduced as a consequence of interface inheritance. The 
> problem was that we wanted to allow diamond inheritance, eg: 
> 
> interface A extends B, C; 
> interface B extends D; 
> interface C extends D; 
> 
> The problem occurs because now it looks like interface A contains 
> two, potentially conflicting, copies of the operations in D. We 
> resolved this by saying that if the copy of D acquired via B is 
> equivalent to the copy of D acquired via C, then all is well. 
> Otherwise there is an error. The two copies will be equivalent if 
> they come from the same document, which is the normal case. However,
> we can't simply compare the URIs used to import or include D because
> it is possible to have two different URIs resolve to the same 
> document. We therefore need to compare the contents of the documents. 
> 
> The definition of component equivalence is recursive and can be 
> computed bottom-up, i.e. two components are equivalent if all their 
> properties are equivalent. Their properities could be either values 
> or component references. If component references, then apply this 
> definition recursively until you hit just values. 
> 
> This would be fine if all component properties could be computed 
> bottom-up. But there are some properties that are computed top-down,
> e.g. in-scope Property and Features, or inherited Operation or Fault
> components. Also, some Extension component properties might be like 
> this. So the definition is a little circular and hard to specify simply. 
> 
> I'd like to propose a simplification. We should eliminate the 
> concept of component equivalence and use infoset equivalence 
> instead. In a sense, the infoset is really where this concept 
> belongs since it arises from considering how we combine documents. 
> The component model has no concept of document. It is built up from 
> the infosets of documents. 
> 
> The impact of this change is that as we are building up the 
> component model, we check to see that duplicate definitions of 
> components have equivalent infosets. If the infosets differ then we 
> have an error and we can't create the component model. The infoset 
> definition is strictly bottom-up and can be computed without 
> reference to derived component model properties. 
> 
> Furthermore, I suggest we apply this notion only to the top level 
> elements: interface, binding, and service, since they are the 
> components that are likely to appear more than once either via 
> import or include or by cut and paste. 
> 
> 2. An implication of the above proposal is that we would disallow 
> "accidental" duplication of operations or faults. For example, the 
> following situation is disallowed: 
> 
> interface A { operation X }; 
> interface B extends A { operation X}; 
> 
> The above is disallowed since operation X is defined in two 
> different interfaces. This is disallowed even if the contents of 
> operation (A/X) is identical to operation (B/X). The appearance of X
> in B is considered to be an accident and an error. 
> 
> Similarly, the following is also illegal: 
> 
> interface A { operation X}; 
> interface B { operation X}; 
> interface C extends A, B; 
> 
> A and B may contain operations of the same name, but an error occurs
> when C extends both of them, even if X is defined identically in 
> both. Designers must factor common operations into a base interface, e.g. 
> 
> interface D {operation X}; 
> interface A {...}; 
> interface B {...}; 
> interface C extends A, B; 
> 
> The same considerations apply to Fault components. 
> 
> An additional motivation for this rule is that now all components 
> have unique URI's. Everyone component is defined in a unique parent 
> component and we can assign it a URI by building up a path composed 
> of the names of its ancestors. In contrast, if we allowed accidental
> equivalence, then in the first example, we only have one operation 
> component X, but is has 2 parents (A and B) and therefore 2 URIs : 
> nsuri#wsdl.operation(A/X) and nsuri#wsdl.operation(B/X). And we 
> would really have to compute its derived properties to determine
 equivalence.
> 
> 3. Finally, for this to work, we should only permit extension 
> elements and attributes in the top level elements: interface, 
> binding, and service. This means they are disallowed as children of 
> the root description element. 
> 
> The motivation for this is that extensions in the root element are 
> scoped to the document, but there is no way to capture this scope 
> within the component model. The only property pushed down from the 
> document to the top level elements is the targetnamespace attribute 
> which becomes the namespace name of the QNames of interface, 
> binding, and service. 
> 
> Allowing root level extensions complicates the definition of infoset
> equivalence of the top level elements since the semantics of the 
> extensions might alter the meanings of the top level element, i.e. 
> attach some inherited properties to them. 
> 
> The consequence is that if an extension is intended to have document
> wide scope, then it must be explicitly copied into all the top level
> elements. However, I am not aware of any such extensions in use today. 
> 
> One other pleasant consequence of this rule is that we can have a 
> deterministic schema that enforces the order of the top level elements,
> i.e.:
> 
> description = 
>         (import | include) * 
>         types ? 
>         (interface | binding | service) * 
> 
> This avoids the need to introduce additional elements to enforce 
> order as I proposed in [2]. 
> 
> [1] http://lists.w3.org/Archives/Public/public-ws-desc-
> comments/2005Jan/0007.html 
> [2] http://lists.w3.org/Archives/Public/public-ws-desc-
> comments/2005Jan/0006.html 
> 
> Arthur Ryman,
> Rational Desktop Tools Development
> 
> phone: +1-905-413-3077, TL 969-3077
> assistant: +1-905-413-2411, TL 969-2411
> fax: +1-905-413-4920, TL 969-4920
> mobile: +1-416-939-5063, text: 4169395063@fido.ca
> intranet: http://labweb.torolab.ibm.com/DRY6/

Received on Saturday, 21 May 2005 04:22:04 UTC