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 Tuesday, 7 May 2002 20:35:59 UTC