Re: Comments on issue 101

It's tempting to suggest that we redefine Envelope as

    <env:Envelope>
      <env:Mandatory>
      </env:Mandatory>
      <env:Optional>
      </env:Optional>
    </env:Envelope>

and put the 'body' inside the Mandatory element. This does raise the problem
of describing the relationship between multiple xml elements intended for
the ultimate recipient as part of the 'body'. Of course we could go for


    <env:Envelope>
      <env:Mandatory>
        <env:Body>
        </env:Body>
      </env:Mandatory>
      <env:Optional>
      </env:Optional>
    </env:Envelope>


or

    <env:Envelope>
      <env:Mandatory>
      </env:Mandatory>
      <env:Optional>
      </env:Optional>
      <env:Body>
      </env:Body>
    </env:Envelope>

These all have the advantage of allowing us to just say in the spec; you
have to understand and process correctly all children of Mandatory and ( for
the latter example ) ( all/first ) child of Body

Gudge


----- Original Message -----
From: "Doug Davis" <dug@us.ibm.com>
To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Cc: "Jacek Kopecky" <jacek@systinet.com>; "Hugo Haas" <hugo@w3.org>;
<xml-dist-app@w3.org>
Sent: Wednesday, October 31, 2001 7:44 PM
Subject: RE: Comments on issue 101


> The problem with that approach is that each header is
> treated as an individual chunk of XML.  Ignoring hrefs
> and actor=none for a moment - each header is in essence
> a separate unit of work - body blocks are not the same.
> The spec specifically says we're not going to deal with
> things like boxcarring so what does multiple independent
> body blocks mean then, if not taken a single unit ?
> -Dug
>
>
> "Henrik Frystyk Nielsen" <henrikn@microsoft.com> on 10/31/2001 01:41:15 PM
>
> To:   "Jacek Kopecky" <jacek@systinet.com>
> cc:   Doug Davis/Raleigh/IBM@IBMUS, "Hugo Haas" <hugo@w3.org>,
>       <xml-dist-app@w3.org>
> Subject:  RE: Comments on issue 101
>
>
>
>
> Thinking more about this I think I was too quick on the trigger. While
> SOAP implementations in many cases dispatch the complete contents of the
> Body element to some "application", the processing model is in fact
> consistent in that all body blocks have to be understood in order for
> the SOAP processor to process the message successfully.
>
> I don't think it makes sense to say that body faults can cause
> mustUnderstand faults simply because this is not how the mustUnderstand
> fault is defined [1]:
>
> "An immediate child element information item of the SOAP Header element
> information item that was either not understood or not obeyed by the
> processing party contained a SOAP mustUnderstand attribute information
> item with a value of "true" (see 4.2.3 SOAP mustUnderstand Attribute)"
>
> In other words, I don't think there is any inconsistency in saying that
> we have a set of body blocks and that they are equivalent to header
> blocks with default actor and mustUnderstand set to true. That the
> mustUnderstand may be interpreted by different parties in any given
> implementation is outside the scope of this specification.
>
> A question is whether we would want to have a Client.Body fault or some
> such to indicate in a generic manner that the body was not understood.
>
> Hope this is more clear
>
> Henrik
>
> >Am I right in this understanding? I think this example should
> >be written in the spec or in the primer because it makes clear
> >that there is no issue about "understanding" (as in mU) of the
> >RPC calls because the receiver has to "understand" env:Body
> >and not m:GetLastTradePrice and thus an unknown method is not
> >an mU fault as has been suggested a few times. 8-)
>
> [1] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#soapfault
>
>

Received on Wednesday, 31 October 2001 16:20:50 UTC