RE: Revised extensibility proposal

Jonathan,

I don't see that what you're saying contradicts the Roberto's latest proposal. If you want to look at it in a simple way, you're more than welcome :). The complex part was a "legal wording" for the spec. One may write a full-sized article then on how simple it is to write extensions for WSDL...

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



-----Original Message-----
From: Jonathan Marsh [mailto:jmarsh@microsoft.com] 
Sent: Tuesday, May 21, 2002 12:53 PM
To: www-ws-desc@w3.org
Subject: RE: Revised extensibility proposal


Personally, the whole thing seems needlessly complex, with Declared Extensions, Undeclared Extensions, Declared Required Extensions, Undeclared Required Extensions, and two syntaxes for indicating Required that will interact in strange ways.  <my:ext wsdl:required="false"/> may in fact be a required extension - you have to look at the prologue to tell.

I still don't see why a simpler proposal won't work:

1) Open the content model to elements and attributes in other namespaces.
2) Mark required extensions with a <wsdl:extension namespace="..."/> element.
3) An interpreter of the WSDL document, encountering an element or attribute marked as a required extension but not recognizing the namespace of that element, must interpret the entire WSDL document as "not understood".
4) Certain elements can accept "architected extensions" which means they don't have to be declared using the extension mechanism.  These are not really extensions at all, just boundaries between embedded namespaces.

Note this also solves the annotation problem.

What is the purpose of marking an optional extension?  What the extension does (optional or required) is certainly the business of the spec for that extension.  The more kinds of extension we introduce, the more we tread into processing models and stray from a declarative language.

> -----Original Message-----
> From: Roberto Chinnici [mailto:roberto.chinnici@sun.com]
> Sent: Friday, May 17, 2002 10:59 AM
> To: www-ws-desc@w3.org
> Subject: Revised extensibility proposal
> 
> Following up on Thursday's conference call, I revised my extensibility 
> proposal. Since we agreed to deal with annotations separately, I 
> removed all
mention
> of them.
> 
> Regards,
> Roberto
> 
> --
> Roberto Chinnici
> Java and XML Software
> Sun Microsystems, Inc.
> 
> ========
> 
> 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. Modify the wsdl grammar (section 2.1 of the spec) to add Extension
>     Declarations immediately inside a wsdl:definition element:
> 
>     <wsdl:definitions name="nmtoken"? targetNamespace="uri"?>
> 
>         <wsdl:extension namespace="uri" required="boolean"?/>*
> 
>         <wsdl:import namespace="uri" location="uri"/>*
> 
>         <!-- rest of the wsdl grammar follows -->
> 
>     The default value for the "required" attribute of the
"wsdl:extension"
>     element is "false".
> 
>     [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.]
> 
>     The "set of extension namespace names" is formed by collecting
>     the values of all the "namespace" attributes of the
"wsdl:extension"
>     elements.
> 
>     The "set of required extension namespace names" is formed by
>     collecting the values of all the "namespace" attributes of the 
> "wsdl:extension"
>     elements whose "required" attribute has a value of "true".
> 
>     [Later on, we'll want to add all built-in extensions to the set of 
> required
>      extension namespace names, so that they don't get declared in
each
>      wsdl document.]
> 
>     [During the conference call, someone (I believe it was Sanjiva) 
> suggested
>      to use a "namespace-prefix" attribute instead of "namespace", in 
> analogy
>      with XSLT. This is purely a matter of syntax that we can discuss 
> later.]
> 
> 3. Keep the wsdl:required attribute (of type xsd:boolean) from WSDL
1.1.
> This
>     attribute is meaningful only when applied to Extensions.
> 
> 4. 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 Declared 
> Extension.
>     All other Extensions are Undeclared.
> 
>     A Declared Extension is Required if: (a) its namespace name is a 
> member of
>     the set of required extension namespace names, or (b) the
Extension
> element
>     itself carries a wsdl:required attribute whose value is "true".
> 
> 5. Mandate the following processing model:
> 
>     a) Extension Declarations
> 
>         A processor that encounters an Extension Declaration whose 
> "required"
>         attribute has the value of "true" and that does not recognize
its
> namespace
>         MUST stop processing the wsdl document at once.
> 
>         A processor that recognizes an Extension Declaration whose 
> "required"
>         attribute has the value of "true" 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 elements that 
> contain
>         Extensions belonging to that particular vocabulary.
> 
>     b) Required Extensions
> 
>         A processor that encounters a Required Extension and that
either
> doesn't
>         recognize its vocabulary or fails to process it successfully
MUST
> stop
>         processing the wsdl document.
> 
>     b) Other Declared Extensions
> 
>         A processor that encounters a Declared Extension which is not 
> Required
>         and whose vocabulary it does not understand MUST ignore it.
> 
>         A processor that encounters a Declared Extension which is not 
> Required
>         and whose vocabulary it understands SHOULD attempt to process
it.
>         In case of failure, the processor MUST continue processing the 
> document
>         as if the Extension had not been present (thus having the same 
> effect as
>         if the Extension's vocabulary had not been recognized by the 
> processor).
> 
>     d) Undeclared Extensions
> 
>         A processor that encounters an Undeclared Extension MUST 
> immediately stop
>         processing the wsdl document; such a wsdl document is deemed 
> invalid.
> 
> 6. Recommendations
> 
>         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.]
>

Received on Wednesday, 22 May 2002 12:17:34 UTC