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

Re: Optional Extensions

From: Prasad Yendluri <pyendluri@webmethods.com>
Date: Wed, 28 Jan 2004 11:58:27 -0800
Message-ID: <40181463.3060304@webmethods.com>
To: Web Services Description <www-ws-desc@w3.org>
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 GMT

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