RE: Optional Extensions

> As David explained, the issue is true backwards 
> compatibility. If someone adds in a new feature that can be 
> safely ignored by old processors they need to know that old 
> processors will ignore the feature. Today the specification 
> doesn't provide any clear guidance on what to do with 
> optional unrecognized extensions. Ideally the spec would say 
> 'the default behavior is to ignore the XML element and its 
> children.' If a tool wishes to override that behavior, that's 
> fine. But interoperability comes from having good defaults 
> and that's what we need the spec to provide.

+1.  I think all we really need to say is that extensions that are not
marked required may be safely ignored by processors.  To Prasad's point,
yes a tool might look at an extension and ask the user whether or not to
charge his credit card $50 to automatically purchase the appropriate
plug-in, or something like that.  The point is merely that such
extensions, if not marked required, should not cause any problems if
ignored.  I doubt many processors are going to dynamically extend
themselves this way, though - it's much more likely the user will
pre-install all the extensions they are interested in or able to deal
with before processing.

> BTW, let's keep in mind that if an extension is not safe to 
> ignore then this is where wsdl:required comes in. We are only 
> talking about extensions that the author of the WSDL had 
> decided could be safely ignored without violating the 
> author's intended meaning or usage of the WSDL.

+1.

--Glen

> > -----Original Message-----
> > From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Prasad Yendluri
> > Sent: Tuesday, January 27, 2004 8:36 AM
> > To: Glen Daniels
> > Cc: Web Services Description
> > Subject: Re: Optional Extensions
> >
> >
> >
> >
> >
> > Glen Daniels wrote:
> >
> > >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.
> > >
> > It *can* give an option to a user of the tool to decide if 
> it should 
> > go ahead ignoring the extensions it did not understand even if they 
> > are optional extensions or minimally issue a warning message (as a 
> > configurable option say). Blindly ignoring and staying 
> silent on the 
> > user is the worst thing a tool can do to a user. I may want 
> to build a 
> > client that understands certain optional extensions I need 
> to use. If 
> > the tool does not handle some of the extensions, I as a 
> programmer may 
> > like to have an option to override and plug in my code as 
> needed or at 
> > least be notified.
> >
> > That way I can decide to buy tool-A that does not 
> understand all the 
> > extensions vs Tool-B that does. May be some tool builders :-D would 
> > not like that.
> >
> > Just putting forth a pragmatic perspective for discussion. 
> Grab some 
> > cool-aid will you!!!
> >
> > > I think this is common sense, but it wouldn't hurt to specify it 
> > >either.
> > >
> > Common sense tells me not to blow my top off silly also :)
> >
> > >
> > >--Glen
> > >
> > >
> > >
> >
> >
> 
> 
>

Received on Tuesday, 27 January 2004 15:21:08 UTC