RE: Extensibility proposal

Roberto,

>>"In what sense was mustUnderstand better? Do you mean the wsdl:required attribute?"

Yes, I meant 'required'. Sorry.

>>"At the same time, I'd like to make sure that such "optional language extensions" do make sense. What would be a good case for them (by which I mean one that is not covered by the other parts of my proposal)?"

Well, first of all, we cannot possibly ensure that all extensions that are added later make sense to us now. But, we need to leave enough flexibility in the standard to allow optional language extensions.

Here is an example I just came up with: a form UI extension. A service designer can place extra descriptions in the WSDL itself to provide "default" UI when a service is directly "experienced" by a "smart device" user. I would love to see something like that. But, it should not prevent normal SOAP client to understand such WSDL and ignore the form UI extension as irrelevant.

>>"as opposed to sprinkling extension elements all over the document and hoping that the processor will do the right thing"

In the lower level reality :) sprinkling extension elements is what the extensions are. It just has to be corrected that the processor that knows about the extension will do the right thing. I like the idea of XML-like extensibility. That means given a WSDL doc, one just extracts information that it knows about (taking into account the 'required') and deals with the service.

Putting all kinds of limitations on extensions will break basic, simple interoperability of a WSDL described service.

I do agree that extensions have to be architected well, but that is out of WSDL scope.

>>"for users as well as for tools, to move away from a purely syntactical notion of extension and try to classify extensions based on their semantics (which, from the point of view of our spec, are reflected in the processing rules attached to them -- hence the distinction that I make between annotations, l-extensions and a-extensions)."

I see that this classification will put a very heavy burden on this working group. We will become sort of a RosettaNet standard body after a while if we start classifying all vocabulary extensions. And if we don't classify them all one by one, then they are just as good as simple plain language extensions all together.

Overall, I like what you have proposed, just two points:
	1. need optional extensions
	2. we don't have to classify or otherwise restrict extensions

-- Igor Sedukhin .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-----Original Message-----
From: Roberto Chinnici [mailto:roberto.chinnici@sun.com] 
Sent: Tuesday, May 07, 2002 8:36 PM
To: Sedukhin, Igor
Cc: www-ws-desc@w3.org
Subject: Re: Extensibility proposal


"Sedukhin, Igor" wrote:

> Roberto,
>
> 1.
>
> I do not agree to
> "A processor that encounters a Language Extension Declaration and does 
> not recognize its namespace MUST stop processing the wsdl document at 
> once."
>
> mustUnderstand was a better way of handling that.

In what sense was mustUnderstand better? Do you mean the wsdl:required attribute?

> If I define a WSDL language extension that is basically optional, I do 
> not want clients to a WS stop working with otherwise perefectly good 
> service.

I see a value in declaring extension vocabularies as such, as opposed to sprinkling extension elements all over the document and hoping that the processor will do the right thing. If you want to express the fact that a certain extension vocabulary is optional, we can certainly do so by adding a new attribute to the wsdl:extension element I proposed to introduce. At the same time, I'd like to make sure that such "optional language extensions" do make sense. What would be a good case for them (by which I mean one that is not covered by the other parts of my proposal)?

> 2.
>
> "The "location" attribute of the wsdl:extension element is for 
> reference purposes only."
>
> I would remove the location to not confuse anyone. It is not needed. 
> Namsepace is sufficient already.

I introduced this attribute speculatively, thinking that in the future we may get a machine-readable description of a language extension, in which case the "location" attribute would indeed become useful.

> 3.
>
> "An Extension of one of these elements and which is
> not a Language Extension is called an Architected Extension."
>
> Why do we need this distinction. Just make them all extensions. We and 
> all users of WSDL have a simpler life thereafter.
>
> You can safely assume binding extensions as language extensions 
> designed to define various protocol specifics.

I disagree. Binding extensions (and architected extensions in general) are localized in scope: they only affect the binding itself. Language extensions don't have this constraint. But of course this is tied to your point #1.

It's clear that we can say "all elements that appear at these points in a document are extensions" and let processors deal with them as they see fit.

The reason I'm putting forward this proposal is that I think that it's better, for users as well as for tools, to move away from a purely syntactical notion of extension and try to classify extensions based on their semantics (which, from the point of view of our spec, are reflected in the processing rules attached to them -- hence the distinction that I make between annotations, l-extensions and a-extensions).

Roberto

--
Roberto Chinnici
Java and XML Software
Sun Microsystems, Inc.


> -- Igor Sedukhin .. (Igor.Sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
>
> -----Original Message-----
> From: Roberto Chinnici [mailto:roberto.chinnici@sun.com]
> Sent: Tuesday, May 07, 2002 12:57 PM
> To: www-ws-desc@w3.org
> Subject: Extensibility proposal
>
> Here's my proposal for extensibility in WSDL.next.
>
> Right now, I won't touch the subject of open attributes, since I feel 
> that if we can agree on element extensibility everything else will 
> fall in place (ever the optimist!)
>
> 1. Allow extension elements on every WSDL element, e.g. by adding
>       <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
>    to every complex type in the WSDL schema.
>
>    Any element matching the rule above is an Extension. An Extension is
>    considered to be an "Extension to" the element containing it (so we can speak
>    of an Extension to a Binding, etc.), or even a "XYZ Extension" (as in
>    "a Binding Extension").
>
> 2. Add to every WSDL element a wsdl:annotation child element thus defined:
>     <xsd:element name="annotation">
>       <xsd:complexType>
>         <xsd:complexContent>
>             <xsd:sequence minOccurs="0" maxOccurs="unbounded">
>               <xsd:any namespace="##other" processContents="lax"/>
>             </xsd:sequence>
>         </xsd:complexContent>
>       </xsd:complexType>
>     </xsd:element>
>
>    Any element that appears as a child of a wsdl:annotation element
>    is an Annotation. Notice that Annotations are *not* Extensions.
>
> 3. Remove the wsdl:required attribute.
>
> 4. Modify the wsdl grammar (section 2.1 of the spec) to add Language
>    Extension Declarations immediately inside a wsdl:definition 
> element:
>
>     <wsdl:definitions name="nmtoken"? targetNamespace="uri"?>
>
>         <wsdl:extension namespace="uri" location="uri"?/>*
>
>         <wsdl:import namespace="uri" location="uri"/>*
>
>         <!-- rest of the wsdl grammar follows -->
>
>     The "set of language extension namespace names" is formed by collecting
>     the values of all the "namespace" attributes of the "wsdl:extension"
>     elements.
>
>     The "location" attribute of the wsdl:extension element is for
>     reference purposes only.
>
>     [Language Extension Declarations are at the beginning of the document
>      so that by the time a processor sees any non-trivial wsdl content,
>      it's aware of all the processing rules.]
>
> 5. Define the following terms:
>
>     An Extension whose element has a namespace name which is a member
>     of the set of extension namespace names is called a Language 
> Extension.
>
>     Certain wsdl elements can declare to have architected extension points
>     (e.g. wsdl:binding). An Extension of one of these elements and which is
>     not a Language Extension is called an Architected Extension.
>
> 6. Mandate the following processing model:
>
>     a) Annotations
>
>         A processor MUST ignore any Annotations that it does not 
> recognize.
>
>         A processor that recognizes an Annotation MAY use the information
>         contained therein during processing. The presence of an Annotation
>         must not modify in any way the processing rules prescribed by this
>         specification and followed by the processor.
>
>     b) Language Extensions
>
>         A processor that encounters a Language Extension Declaration and
>         does not recognize its namespace MUST stop processing the wsdl
>         document at once.
>
>         A processor that recognizes a Language Extension Declaration MUST
>         obey its rules for the entire duration of its processing of the wsdl
>         document in which it appears. Such rules are allowed to override other
>         wsdl processing rules defined by this specification.
>
>         It is recommended that the effect of these rules be as localized as possible;
>         in particular, their effect SHOULD be local to the elements that contain
>         Language Extensions belonging to that particular vocabulary.
>
>         Language Extensions that define new globally named constructs (e.g. the
>         way wsdl portType, message, binding and service do) SHOULD appear as
>         children of the wsdl:definitions element; moreover, they SHOULD define
>         their own symbol space and they SHOULD follow the QName resolution rules
>         that this specification defines.
>
>         [Hopefully, this will make it easier to use two extensions at the same time,
>         although in general all bets are off.]
>
>     c) Architected Extensions
>
>         A processor that encounters an Architected Extension that it does not
>         recognize MUST flag the element that directly contains it as 
> "not understood".
>
>         [Note: we should define what the implications of not understanding
>          an element are. Intuitively, if a processor does not recognize an
>          Architected Extension of, say, a binding, it does not fully understand
>          the binding itself, so it cannot make any practical use of it. This is
>          not reason enough, though, to reject the whole document.]
>
>     d) Other Extensions
>
>         A processor that encounters an Extension element which is neither
>         a Language Extension nor an Architected Extension MUST stop processing
>         the wsdl document at once; such a wsdl document is deemed 
> invalid.
>
>         [Of course, this rule can be overridden by a Language 
> Extension !]
>
> Comments?
>
> Roberto
>
> --
> Roberto Chinnici
> Java and XML Software
> Sun Microsystems, Inc.

Received on Wednesday, 8 May 2002 11:16:37 UTC