W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2001

Re: Issue 146 proposed resolution

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
Message-ID: <OF10CD2743.067F18C0-ON85256B06.0081E48D@raleigh.ibm.com >
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 GMT

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