LC105 Recap

My only remaining issue in LC105 concerns the interaction between 
extensions and equivalence of top-level components.

The problem is that a WSDL document may include or import two definitions 
of the same top level component (interface, binding, service). We need a 
simple way to check if the two definitions are equivalent. Consider the 
following two documents:


interface1.wsdl:

<description ...>
        <interface name="MyInterface".../>
</description

interface2.wsdl:

<description ..x:extension-attribute="value".>
        <x:extension-element../>
        <interface name="MyInterface".../>
</description

Suppose the definition of MyInterface is identical in both documents. Are 
they equivalent?

The spec seems to allow for the possibility that they are not equivalent 
because x:extension-attribute or <x:extension-element> might alter the 
component model in interface2.wsdl. This means that we have to in effect 
construct the component models and execute the semantics of the extensions 
and then compare the component models in order to see if they are 
equivalent. 

This seems complex and a lot of work. It would be desirable if we could 
make some restrictions so that it was easy to compare the documents for 
equivalence without building the component models.

I propose the following:

1. A top level extension attribute or element MAY add only top level 
extension components, i.e. it MAY NOT add top level attributes (since 
their scope gets "lost" when we combine documents), and it MAY NOT 
directly affect other top level components.

2. A nested extension attribute or element MAY add only extension 
components or properties to its parent component, and it MAY NOT directly 
affect other sibling nested components.

3. Components are equivalent if their value properties are equal, and 
their component reference properties either a) refer to equivalent 
components in the case of children components, or b) refer to components 
that have the same names in the case of non-children components.

1 and 2 clarify and restrict the scope of extension attributes and 
elements. This is probably a change in the semantics of the current spec, 
but there is very little written about extensions so it is hard to tell 
what the intension was.

3 simplifies the computation of component equivalence by making it depend 
only of the definition of components within a document. The children of a 
component are always in the same document, but the other referenced 
components may be in other documents. If the other referenced components 
are equivalent then they have the same names. If they are not equivalent, 
then we have an invalid component model anyway. Here name means their URIs 
which takes into account their nested context and uniquely identifies 
them. This doesn't change the semantics of the current spec.

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/