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/