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:03:44 -0400
Message-ID: <849C1D32E4C7924F854D8A0356C72A9E0425BF9F@usilms08.ca.com>
To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>, Roberto Chinnici <roberto.chinnici@sun.com>, www-ws-desc@w3.org
Sanjiva,

>>"<wsdl:extension prefix="p" required="boolean"?/>*"

This does not look standard way of treating namespaces. That is when taken into an XML DOM it does not have to preserve those prefixes, really. It is not required by the DOM spec. The relationship may be lost. Just try to subscribe to a WS using .NET. All prefixes will be renamed to their own model, while, of course, namespace to element reationships are kept.

It's not a big deal to have something like this
<wsdl:definitions xmlns:myext="uri:myorg-myext"...
<wsdl:extension namespace="uri:myorg-myext"/>
...<myext:myextra ...

Then using a DOM parser one can sinply query what namespace myext:myextra belongs and that way make decisions.

>>"I suggest that we make the required attribute default to true."

Now, you mean required on wsdl:extension, right? That would be okay.
Although, we cannot make wsdl:required attribute default to true for *all* elements regardless!

-- Igor Sedukhin .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
Sent: Tuesday, May 21, 2002 1:28 AM
To: Roberto Chinnici; www-ws-desc@w3.org
Subject: Re: Revised extensibility proposal


Hi Roberto,

This looks good to me. The syntax I was proposing was:

   <wsdl:extension prefix="p" required="boolean"?/>*

where there should be an in-scope namespace declaration for the prefix p. That just makes life a bit easier by not forcing one to write the same NS URI twice.

I suggest that we make the required attribute default to true.

I'm not quite clear on item (6) of your list. Can you clarify what you have in mind please?

I think we also need to add wording to the effect that extensions are not allowed to change the defined behavior of any WSDL elements. (The XSLT spec has wording that can be used as sample.) Basically, we shouldn't allow extensions to change the semantics of any spec defined constructs!

Bye,

Sanjiva.

----- Original Message -----
From: "Roberto Chinnici" <roberto.chinnici@sun.com>
To: <www-ws-desc@w3.org>
Sent: Friday, May 17, 2002 11:58 PM
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:06:37 GMT

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