RE: Proposal for LC80: Contribution of Extensions to the Componen t Model

If you bear in mind that I co-chair the UDDI Tech Committee at OASIS,
you will see why it is that I was surprised to see a WS-Desc e-mail with
"tModel" in the subject...

Tony Rogers
tony.rogers@ca.com

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Asir Vedamuthu
Sent: Thursday, 21 April 2005 13:21
To: 'Arthur Ryman'; www-ws-desc@w3.org
Subject: RE: Proposal for LC80: Contribution of Extensions to the
Componen t Model


My comments, questions, ..

> 3. An extension property is identified by a QName whose namespace name

Would it be fair to say that the following names are invalid (because we
don't use any namespace name):

{soap version}
{soap underlying protocol}
{soap fault code}
...


> extension property type is one of the following: an XML Schema Type, a
REQUIRED component reference, an OPTIONAL component reference

You are mixing two dimensions: occurrence (required/optional) and type


> an extension type (as allowed by WSDL type extensibilty)

What is the difference between XML Schema type and an extension type?
Aren't they the same? May be, you are referring to XML Schema built-in
type as XML Schema type.


> An extension component is identified by a QName whose namespace is the

> extension namespace

Would it be fair to say that the following component names are invalid
(because, we don't use a namespace name):

SOAP Module Component
SOAP Header Component
HTTP Header Component


> An extension component type specification therefore consists of a 
> (name, properties, extensible) triple where

SOAP Binding allows 7 of the HTTP Binding properties, such as {http
version}, {http location}, {http .. Given that, what additional prose
should we add to make sure that Part 2 conforms to these new rules for
extension?


PS: (my personal comment) these are sizable changes to Part 2. Property
names can get ugly, example {http://www.w3.org/@@@@/@@/wsdl/soap,
version}.
I hope that we ship WSDL 2.0 ASAP !

Regards,
Asir S Vedamuthu
asirv at webmethods dot com
http://www.webmethods.com/ 

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Arthur Ryman
Sent: Wednesday, April 13, 2005 11:17 AM
To: www-ws-desc@w3.org
Subject: 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/

Received on Tuesday, 26 April 2005 00:11:35 UTC