Re: Issue 146 proposed resolution

Providing an example that doesn't show the problem
doesn't convince me.  8-)
How about the fireNuke example we had back in France:
<Header>
  <c:fireNuke xmlns:c='http://us.gov/potus' mu='1'/>
  <c:getAuthorization xmlns:c='http://us.gov/potus' mu='1'/>
</Header>
but now add an actor:
<Header>
  <c:fireNuke xmlns:c='http://us.gov/potus' mu='1'/>
  <c:getAuthorization xmlns:c='http://us.gov/potus'
      actor="checker" mu='1'/>
</Header>
There's a little bit of trouble if the "checker" actor isn't hit.
In "core" soap there is no way at all to use a header
targeted for anyone but "next" or the ultimate recipient
and guarantee that it will be processed or a fault will
be thrown.  Its useless w/o an extension.
I don't necessarily want MU to be mustHappen (that is one
option, making mustHappen part of "core" soap is another),
what I would like is an agreement that this is a valid
problem that we should look into but until then whenever someone
says "the spec isn't broken" I will continue to say and believe
that it is (IMO of course).

-Dug


Noah_Mendelsohn@lotus.com on 11/16/2001 07:10:26 PM

To:   Doug Davis/Raleigh/IBM@IBMUS
cc:   distobj@acm.org, henrikn@microsoft.com, marting@develop.com,
      skw@hplb.hpl.hp.com, xml-dist-app@w3.org
Subject:  Re: Issue 146 proposed resolution



You have raised this concern before, and we have discussed it several
times.  A concrete example of where the current design is useful
(namespaces left off and pseudo-URI's used for brevity):

        <Header>
            <dontCacheThisMessage actor="anyCachingIntermediary"
mustUnderstand="1"/>
        </Header>
        <Body>
          <getAccountBalance> ... </getAccountBalance>
        </Body>

There's no reason at all there should be any trouble if this message
doesn't happen to pass a caching server.  If it does, it's essential that
that caching intermediary understand the "don't cache" instruction. What's
broken?  It's simple and it works.

I know you have said repeatedly that you would like mustUnderstand to have
a mustHappen semantic.  It doesn't, but as we have said you can introduce
various flavors of mustHappen as headers which are themselves
mustUnderstand?   Separating these two concepts strikes me as a good, not
a bad thing.

Is there new information on this question at this point?  It really looks
to me like something that we discussed in detail and settled (in Rennes).
Thanks

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







"Doug Davis" <dug@us.ibm.com>
11/16/01 06:50 PM


        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
        Subject:        Re: Issue 146 proposed resolution


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 20:05:48 UTC