Re: Optional Extensions

This works for me. Will there be an issue with clearly defining what 
"fault"ing is however.

Regards, Prasad

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? 
>
>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.
>  
>