- From: Doug Davis <dug@us.ibm.com>
- Date: Tue, 15 May 2001 15:51:53 -0400
- To: Noah_Mendelsohn@lotus.com
- Cc: xml-dist-app@w3.org
Perhaps I wasn't clear - if someone doesn't use the feature then they're stuck using the current SOAP spec, and if we don't change the current spec then they're also stuck with the current ambiguity. So, I believe that whether or not we do a feature like this we still need to update the spec. -Dug Noah_Mendelsohn@lotus.com@w3.org on 05/15/2001 10:13:16 AM Sent by: xml-dist-app-request@w3.org To: Doug Davis/Raleigh/IBM@IBMUS cc: xml-dist-app@w3.org Subject: Re: An analysis of mustUnderstand and related issues Doug Davis writes: >> Just wondering, if we go with this >> approach, what does it mean if >> people don't use it? My suggestion would be, when you don't use the new feature, you get SOAP semantics. Behavior would change only on headers where the new attributes were actually used: * if a header says mustHappen, then when processed your header must be replaced by hasHappened * if a header says dependsOn, then fault if precursors haven't happened Other than that, not changes I think. Keep in mind, this proposal is intended as a point of discussion. I think it's worth considering, but we should compare it to whatever alternatives before becoming wedded to it. Even if we like the general idea, I think we should definitely explore the alternatives for exactly how we represent the dependency information in the message. For example, I'm starting to change my mind: maybe we can find a convention that's reasonably convenient and also models as a clean "module" (I.e. the existing mustUnderstand is used on some header to ensure that the new features are understood.) I have some rough ideas on how to do this, which I will try to set down if I hit any breaks in the W3C schema meeting (where I am for the next two days.) Thanks. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
Received on Tuesday, 15 May 2001 15:52:02 UTC