Re: Extensibility proposal

We can certainly do that.

One additional benefit of my proposal, though, is that it would let processors
tell annotations and language extensions apart from what I call "architected
extensions". It's not clear to me how that could happen if annotations were
allowed to appear everywhere.

The other aspect which I value in a language extension is the fact that
it declares a whole vocabulary. Elements belonging to that vocabulary
can appear at different places in a document and yet have subtly
intertwined effects on processors. I don't see annotations as having
this quality at all, so they don't match my intuition of "optional language
extensions".

Roberto


Jonathan Marsh wrote:

> 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 19:18:11 UTC