W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2005

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

From: Asir Vedamuthu <asirv@webmethods.com>
Date: Wed, 20 Apr 2005 20:20:42 -0700
Message-ID: <5B10E50E14A4594EB1B5566B69AD9407068E6B77@maileast>
To: 'Arthur Ryman' <ryman@ca.ibm.com>, www-ws-desc@w3.org

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 Thursday, 21 April 2005 03:20:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:35 GMT