RE: Extensibility proposal

It looks like your proposal forces some redundancy.  You mark extensions
using an <wsdl:extensions> element, and you mark annotations by placing
them within a <wsdl:annotations> element.  Why not simply say that any
namespaced element/attribute not designated as a required extension by
<wsdl:extensions> is an annotation?

This solves the convenience problem of using attribute-based
annotations.  For instance, Igor's concern over the "location" attribute
might be solved by allowing the purpose to be served by an annotation.

  <wsdl:extension namespace="uri" my:location="uri"?/>

BTW, I think my/your term "annotation" is Igor's term "optional language
extension".

> -----Original Message-----
> From: Roberto Chinnici [mailto:roberto.chinnici@sun.com]
> Sent: Tuesday, May 07, 2002 9:57 AM
> 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 18:04:50 UTC