RE: Extensibility proposal

I agree that anotations have different semantics. It's nice to have annotations. I also agree that we should not qualify them as 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: Wednesday, May 08, 2002 7:18 PM
To: Jonathan Marsh
Cc: www-ws-desc@w3.org
Subject: 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 Thursday, 9 May 2002 10:54:28 UTC