- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Tue, 27 Jan 2004 10:31:49 -0500
- To: "Prasad Yendluri" <pyendluri@webmethods.com>, "Web Services Description" <www-ws-desc@w3.org>
I'm sorry, but I don't understand this whole "may ignore them" business. What exactly is a processor going to do with an extension it doesn't understand? IMHO, it has to ignore them unless they are marked as required, in which case it fails. I think this is common sense, but it wouldn't hurt to specify it either. --Glen > -----Original Message----- > From: www-ws-desc-request@w3.org > [mailto:www-ws-desc-request@w3.org] On Behalf Of Prasad Yendluri > Sent: Monday, January 26, 2004 4:51 PM > To: 'Web Services Description' > Subject: Re: Optional Extensions > > Hi, > > We should follow the recommendation in section 6.1.1 in the > WSDL 2.0 core, for "mandatory" extensions. If wsdl:required > is false, the WSDL processor MAY ignore them. I mean it could > be a configurable option by the user of the processor, rather > than blindly ignoring them always. > > Prasad > > > 6.1.1 Mandatory extensions > > > Extension elements can be marked as mandatory by annotating > them with a wsdl:required attribute information item (see > 6.1.2 required attribute information item > <http://www.w3.org/TR/wsdl20/#required-aii> ) with a value of > "true". Mandatory extensions are those that MUST be processed > correctly by the WSDL processor. If a mandatory extension > element is processed, the WSDL processor MUST either agree to > fully abide by all the rules and semantics signaled by the > extension element's qualified name, or immediate cease > processing (fault). In particular, if the WSDL processor does > not recognize the qualified name of the extension element, it > MUST fault. If the WSDL processor recognizes the qualified > name, and determines that the extension in question is > incompatible with any other aspect of the document (including > other required extensions), it MUST fault. > > -------- Original Message -------- > Subject: RE: Optional Extensions > Date: Mon, 26 Jan 2004 13:11:51 -0800 > From: Philippe Le Hegaret <plh@w3.org> > <mailto:plh@w3.org> > To: David Orchard <dorchard@bea.com> > <mailto:dorchard@bea.com> > CC: 'Web Services Description' <www-ws-desc@w3.org> > <mailto:www-ws-desc@w3.org> > > On Mon, 2004-01-26 at 15:47, David Orchard wrote: > > Philippe, you are not understanding the relationship > between ignoring > > content and extensibility/versioning. If somebody makes a backwards > > compatible change to their wsdl by putting in an optional > > extension,they want to make sure that folks that don't know about > > their extension will not fall over and die. By underspecifying the > > behaviour of optional extensions in wsdl, they do not have an > > assurance that their change is backwards compatible. By requiring > > that unknown extensions are ignored, there are assurances of > > compatible evolution. This model worked very well for HTML > and HTTP headers, and is embodied in the soap:mustUnderstand > attribute. > > There is extensive precedence for this. > > Rereading your original, I now realize that you were talking > about the WSDL processors in the context of unknown optional > extensions, and not WSDL processors in the context of > optional extensions... I would propose that WSDL processors > MUST ignored unknown optional extensions if any, and MAY > process known optional extensions. > > Philippe > > -------- Original Message -------- > Subject: Optional Extensions > Resent-Date: Mon, 26 Jan 2004 14:50:19 -0500 (EST) > Resent-From: www-ws-desc@w3.org > Date: Mon, 26 Jan 2004 11:51:29 -0800 > From: David Orchard <dorchard@bea.com> > <mailto:dorchard@bea.com> > To: <www-ws-desc@w3.org> <mailto:www-ws-desc@w3.org> > > If there is a WSDL extension which is not mandatory and not > recognized by the WSDL processor what is to be done with it? > Our suggestion is that it should be ignored, and that this > should be specified. Same thing applies to extension attributes. > > Cheers, > Dave > >
Received on Tuesday, 27 January 2004 17:16:49 UTC