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

Re: Optional Extensions

From: Amelia A Lewis <alewis@tibco.com>
Date: Wed, 28 Jan 2004 14:10:47 -0500
To: Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
Cc: www-ws-desc@w3.org
Message-id: <20040128141047.45005c8a.alewis@tibco.com>

On Wed, 28 Jan 2004 11:01:13 -0800
Jeff Mischkinsky <jeff.mischkinsky@oracle.com> wrote:
> 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?

I would say yes.  You *can't* fault on an unknown optional extension,
and be compliant.  You can warn.  You can put BIG RED LETTERS on the
console and screamers in the logs, but you can't fault.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com
Received on Wednesday, 28 January 2004 14:15:59 GMT

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