- From: Doug Davis <dug@us.ibm.com>
- Date: Fri, 16 Nov 2001 18:50:21 -0500
- To: Noah_Mendelsohn@lotus.com
- Cc: "Martin Gudgin" <marting@develop.com>, distobj@acm.org, henrikn@microsoft.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org
Without going into the specifics of this proposal, I do believe that the current spec if very much broken with respect to something we talked about a long time ago: MU=1+actor where that actor is never hit. IMO, if you use a user-defined actor (ie. not "next") using MU=1 too is a completely useless feature. "Useless" because no one should *ever* use it. Why would a sender ever use MU=1+actor if there is no guarantee that that actor will ever be hit - and the MUness was obviously important to the sender - but they're never told that that header was never processed. So, who would ever send any critical data in that header? The answer should be "no one" - thus its a useless feature. I know we talked about this and yes using an extension like "mustHappen" could solve it but that doesn't excuse the fact that "core soap" has this useless feature. This is one of my biggest annoyances with "actor" (and I guess MUs) - and IMO the "core" spec is broken as a result. -Dug Noah_Mendelsohn@lotus.com on 11/16/2001 06:20:27 PM To: "Martin Gudgin" <marting@develop.com> cc: distobj@acm.org, Doug Davis/Raleigh/IBM@IBMUS, henrikn@microsoft.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org Subject: Re: Issue 146 proposed resolution I think the reason not to do this is that the SOAP processing model then doesn't apply directly to the header entries: it applies only to the immediate children of <Header> and <Body>. Of course, we could give the processing model knowledge of the <Actor> attribute, which would put it in the core. I do see that by marking this mU, you can write a spec for <Actor> that says: add my children to the headers to be processed per chapter2, and process me really really first so that my mU checks are done before any other processing. Still, a situation like this: <envelope> <header> <block1>...</block1> <block2>...</block2> <actor href='actoruri' mustUnderstand ='true' > <block3 mustUnderstand="false"> ... </block3> <block4 mustUnderstand="true"> ... </block3> </actor> <block5> ... </block5> </header> <body> ... </body> </envelope> looks very conceptually messy if blocks 1,2,5 and <actor> are processed per chapter 2 rules, with 3 and 4 being the business of the specification for the Actor extension. I too have been nervous about he complexity/benefit ratio of intermediaries, but I think it's very late in the game to be having this debate. We've had a year to get these things right, we're trying to get to last call, and unless it's deeply broken I think we should tune it up and go ahead. I'm not yet convinced that it's broken, or that doing it as an extension actually works well. Thanks! ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------ "Martin Gudgin" <marting@develop.com> 11/16/01 05:39 PM To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>, "Mark Baker" <distobj@acm.org> cc: <Noah_Mendelsohn@lotus.com>, "Doug Davis" <dug@us.ibm.com>, <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org> Subject: Re: Issue 146 proposed resolution Why not this? <actor href='actoruri' mustUnderstand='true' > <myHeader1/> <myHeader2/> <myHeader3/> </actor> <actor href='someotheractoruri' mustUnderstand='true'> <myHeader3/> <myHeader4/> </actor> Gudge ----- Original Message ----- From: "Mark Baker" <distobj@acm.org> To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> Cc: "Martin Gudgin" <marting@develop.com>; <Noah_Mendelsohn@lotus.com>; "Doug Davis" <dug@us.ibm.com>; <skw@hplb.hpl.hp.com>; <xml-dist-app@w3.org> Sent: Friday, November 16, 2001 7:40 AM Subject: Re: Issue 146 proposed resolution > +1 (sorry Gudge, only [-1,+1] 8-) > > I see no merit to that proposal. > > > Only as a mandatory extension and only by effectively redeploying *all* > > existing SOAP nodes. > > Right, plus we wouldn't be able to keep the existing attribute based > syntax, since our mandatory extension mechanism is element based. > We'd have to have something like; > > <header> > <myheader id="foo" ... /> > ... > <actors mustUnderstand="1"> > <actor ref="foo" value="http://..."> > <actor ref="some-other-id-to-another-header" value="http://..."> > </actors> > ... > > Blech! > > MB > -- > Mark Baker, CSO, Planetfred. > Ottawa, Ontario, CANADA. > mbaker@planetfred.com
Received on Friday, 16 November 2001 18:50:45 UTC