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

Received on Tuesday, 18 June 2002 18:18:43 UTC