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:33:50 UTC