RE: Extensibility proposal

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.

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.

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.

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.

-- 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 15:23:12 UTC