- 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
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 UTC