Proposal for LC80: Contribution of Extensions to the Component Model

This issue concerns how Extensions are described in Part 1, and used in 
Part 2. Extensions are very important since, for example,  they are the 
mechanism by which bindings are defined. Part 1 is written in terms of an 
Abstract Component Model. Therefore, Part 1 should specify how generic 
Extensions contribute to the Component Model. Part 2 should then specify 
how the defined Extensions contribute to the Component Model according to 
the rules given in Part 1.

Part 1 currently states that WSDL 2.0 documents may contain elements and 
attrributes from other namespaces, and that these may contribute 
properties and components to the component model. I propose that Part 1 be 
more precise about how extensions contribute to the component model.

Part 1 currently states:

1. An extension has a namespace that is different than the WSDL 2.0 
namespace. An extension defines XML Infoset elements and attributes in its 
namespace. 

2. An extension MAY contribute extension properties and extension 
components to the component model.

I propose we add the following:

3. An extension property is identified by a QName whose namespace name is 
the extension namespace. An extension property has a type that constrains 
its allowed values. An extension property type is one of the following:
         an XML Schema Type, 
        a REQUIRED component reference
        an OPTIONAL component reference
        a set of zero or more component references
        an extension type (as allowed by WSDL type extensibilty)

An extension property type specification therefore consists of a (name, 
type) pair where:
        name is the extension property QName and 
        type is the extension property type.

4. An extension component is identified by a QName whose namespace is the 
extension namespace. An extension component contains zero or more 
extension properties from its own namespace. An extension component may 
itself be extensible, in which case it contains zero or more extension 
components from other namespaces.

An extension component type specification therefore consists of a (name, 
properties, extensible) triple where 
        name is the extension component type QName, 
        properties is a set of zero or more extension property type QNames 
from its own namespace, and 
        extensible is a boolean that is true if and only if the extension 
component type is itself extensible.

5. An extension SHOULD have an XML Schema that defines its elements and 
attributes.


The reason that we should use QNames to identify extension property and 
component types is to avoid name collisions in the component model. This 
lets extensions compose cleanly. For example, it's possible now that two 
extensions could both contribute properties to a component. QNames are 
designed to manage namespaces.

The reason we should be specific about the types is to permit the 
development of APIs for extensible tools.

If the above proposal is accepted, Part 2 should be updated to include the 
precise extension property type and extension component type definitions.

In the course of reviewing the spec, I noticed that the language is fairly 
inconsistent. Sometimes we say extension element, and sometimes we say 
extensibility element. We should be consistent. I suggest we just say 
extension. Also, sometimes we refer to elements and sometimes to element 
and attributes. For example, bindings could be defined using attributes, 
but the spec only refers to elements. We should simple say extensions to 
cover both cases.

Finally, in 6.1 there is a reference to substitution groups. We dropped 
that, didn't we?
The WSDL schema also defines a base type for use by extensibility 
elements. Example 6-1 shows the type definition. The use of this type as a 
base type is optional. The element declarations which serve as the heads 
of the defined substitution groups are all of type "xs:anyType".


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/