- From: Prasad Yendluri <pyendluri@webmethods.com>
- Date: Wed, 28 Jan 2004 11:58:27 -0800
- To: Web Services Description <www-ws-desc@w3.org>
- Message-ID: <40181463.3060304@webmethods.com>
Good point. What if the definition of the optional extension is "faulty" :). Well I guess we would have come full circle on this if we do end up with optional extensions MAY be ignored. Glen Daniels wrote: >I don't think you can ever say that something MUST not fail. I can choose >to fail on any condition I want, including using XML elements from a >particular namespace, running after closing time, etc. > >I believe all we can say is that optional extensions may be safely ignored. > >--Glen > >----- Original Message ----- >From: "Jeff Mischkinsky" <jeff.mischkinsky@oracle.com> >To: "Liu, Kevin" <kevin.liu@sap.com>; "'Prasad Yendluri'" ><pyendluri@webmethods.com>; "Glen Daniels" <gdaniels@sonicsoftware.com> >Cc: "Web Services Description" <www-ws-desc@w3.org> >Sent: Wednesday, January 28, 2004 2:01 PM >Subject: RE: Optional Extensions > > > > >>At 10:18 AM 1/28/2004, Liu, Kevin wrote: >> >> >> >>>I see the value of both sides of the argument. From the service >>>perspective, assurance of backward compatibility is >>>desireable(non-required extension will not break its current clients); >>> >>> >>>from the service users perspective, it maybe a good thing to be at least >> >> >>>warned that some not-understandable optional extension is encountered. >>> >>>In stead of saying that the processor MUST *ignore* the >>> >>> >not-understandable > > >>>optional extension, would it be better to say that the process MUST NOT >>> >>> >fault? > > >>I like this better. But what happens if i want to be super-strict/paranoid >>and implement a policy (lower case policy :-) and be very sure that I >>understand everything in my environment, i.e. i'm not willing to trust >>someone that something is ignorable. What are my choices if we go down >> >> >this > > >>path? Is my only alternative to be non-compliant? >> >>cheers, >> jeff >> >> >> >> >>>Best Regards, >>>Kevin >>> >>> >>>-----Original Message----- >>>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On >>>Behalf Of Prasad Yendluri >>>Sent: Tuesday, Jan 27, 2004 02:15 PM >>>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 >>>> >>>> >>>> >>>> >>>> >>Jeff Mischkinsky jeff.mischkinsky@oracle.com >>Consulting Member Technical Staff +1(650)506-1975 >>Director, Web Services Standards 500 Oracle Parkway M/S 4OP9 >>Oracle Corporation Redwood Shores, CA 94065 >> >> >> >>
Received on Wednesday, 28 January 2004 14:59:07 UTC