W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2002

RE: Revised extensibility proposal

From: Sedukhin, Igor <Igor.Sedukhin@ca.com>
Date: Tue, 21 May 2002 11:52:19 -0400
Message-ID: <849C1D32E4C7924F854D8A0356C72A9E0425CA04@usilms08.ca.com>
To: Roberto Chinnici <roberto.chinnici@sun.com>, www-ws-desc@w3.org
I like this. +1

-- 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: Friday, May 17, 2002 1:59 PM
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 Tuesday, 21 May 2002 11:52:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:20 GMT