RE: Text for extensibility section

Jeff,

>>To indicate that a set of extensions are "must recognize", you would be required to annotate 
>>at least one EII E with wsdl:required='true' as a child of a WSDL-defined EII, but the semantics 
>>of "recognizing" E would be defined in a separate specification. That specification could indicate 
>>that "recognizing" means "must recognize" or "may recognize" for any number of other EII or AII, 
>>even if the latter were in different XML namespaces.

I think I hear the point, but isn't it overly complicated to do a very simple thing? I mean this set of implicit rules of "annotating at least one" and it kinda affects related extensions (not even in the same namespace). Also "requiredness" rules defined in another namespace. It sounds a little convoluted for simply indicating that a set of elements and attributes are required to process in a WSDL document.

I see that at some point WSDL processors would have to use an inferencing engine to merely decode all the implicit dependencies from a set of extension elements and their "requiredness" rules.

It would also make very hard to design and use an extension, which should be very simple for the sake of proper interop.

I guess I'll read minutes of F2F in more detail, but if you could recall, what was the main objection of doing <wsdl:requiredExtension namespace="<URI>"/> ?

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



-----Original Message-----
From: Jeffrey Schlimmer [mailto:jeffsch@windows.microsoft.com] 
Sent: Tuesday, June 18, 2002 6:18 PM
To: www-ws-desc@w3.org
Subject: RE: Text for extensibility section



Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com] wrote:
>The proposed extension spec text talks about an extension element and 
>its >Qname. It does not define this parent/child inheritance of the 
>>"requiredness" that you're referring to. At least as I read it. Here is the >quote: "
>> If an extension element is processed, and has a "wsdl:required"
>> attribute with the value "true", the processor MUST either agree to 
>> fully abide by all the rules and semantics signalled by the extension 
>> element's QName, or immediately cease processing (fault).  In 
>> particular, if the processor does not recognize the QName it must 
>> fault.  If it does recognize the QName, and determines that the 
>> extension in question is incompatible with any other aspect of the 
>> document (including other extensions), it must also fault. 
>"
>So reading the above, I don't understand how can I hang a wsdl:required off >an extension attribute such as in 

The wording Glen provided was to address the specific point of how a "must recognize" extension element could indicate a scope of recognition. His wording does not address the open content model we agreed to earlier. One may put a foreign AII A on any WSDL-defined EII W. To indicate that A is "must recognize", one must put an EII E as a child of W with wsdl:required='true' and associate E with A via a separate specification.

>I also don't follow on, *from the above text*, how in
>        <portType myExt:abc="def"... 
>        <myExt:allExts wsdl:required="true"/> 
>myExt:abc and myExt:allExts would be related. They are different Qnames, >and therefore rule applies separately to each one.
>I understand you point, but if so, it should be formalized somehow in a >spec. 

I agree we should be clearer about this. We did discuss it at length during the face to face meeting last week, and I believe the common case will be where the XML namespace is shared, but there is no requirement that they do so. Generally, what it means to "recognize" an extension is defined by that extension, not by our WSDL specification.

>If I have a namespace full of top-level elements and attributes used to 
>>extend WSDL constructs, why should I  now be grouping all of them 
>under >another element to merely indicate requiredness of that 
>extension?

No. To indicate that a set of extensions are "must recognize", you would be required to annotate at least one EII E with wsdl:required='true' as a child of a WSDL-defined EII, but the semantics of "recognizing" E would be defined in a separate specification. That specification could indicate that "recognizing" means "must recognize" or "may recognize" for any number of other EII or AII, even if the latter were in different XML namespaces.

>Moreover, if I add ten more top-elements, then I'd have to remember to 
>add >them to that grouping element.

No. You'd only have to include one, and it wouldn't have to be a wrapper for the others. 

>Well, I've already done the grouping by putting all those elements in a 
>>particular namespace identified by a URI. Isn't it enough?

Yes. You could do this by defining an EII with the semantics that it implies "recognition" and other processing rules for a set of other EII and/or AII.

>Can't I simply >say
><wsdl:requiredExtension namespace="<URI>"/>

Technically no. We decided to stick with the wsdl:required syntax for familiarity.

>I thought that is where we left off on the last call and it was kinda 
>close >to be finalized that way... What has happened?

After extensive discussion, my recollection is that we decided three things:

(a) We liked the value of being able to declare an extension within a scope, thus the new wording from Glen. One can still use the "global" scope by adding the EII with wsdl:required='true' to wsdl:definitions.

(b) We kept wsdl:required AII because it was sufficient.

(c) We didn't restrict the relationship between the EII that is marked with wsdl:required='true' and other EII and/or AII. Such a relationship is truly beyond the scope of WSDL and the purview of the individual EII/AII.

--Jeff