W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2004

RE: Optional Extensions

From: Yaron Goland <ygoland@bea.com>
Date: Tue, 27 Jan 2004 11:46:21 -0800
To: "'Prasad Yendluri'" <pyendluri@webmethods.com>, "'Glen Daniels'" <gdaniels@sonicsoftware.com>
Cc: "'Web Services Description'" <www-ws-desc@w3.org>
Message-ID: <044001c3e50e$3dbb8c30$65e5e40c@bea.com>

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.

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.

	Yaron

> -----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 14:46:33 GMT

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