Re: mid-course correction on abstract model for module processing

Again,

I'd have to ask the inevitable question: "what does processing mean?"

If processing==parsing then Header/Body would only potentially 
allow for Header to be processed without needing (necessarily) to 
parse the Body.

However, most SOAP implementations with which I am familiar
process (parse) the entire Envelope and pass this on to
the registered handlers as appropriate, so unless the substantive 
matter of the Body is actually a reference (ala SMwA) to something
that is not part of the Envelope, nothing is gained by the 
semantic differentiation between Header and Body because both
must be parsed anyway.

I too favor the elegance of a single construct that can be
semantically differentiated by something like the actor and/or namespace
qualifier. Certainly, there can be an abstraction made that
for handlers masks the actual XML content and makes it appear
that there is a Header and a Body...

Cheers,

Chris

Mark Jones wrote:
> 
>         Date: Mon, 2 Apr 2001 17:16:24 -0400
>         From: Hugo Haas <hugo@w3.org>
>         To: xml-dist-app@w3.org
>         Subject: Re: mid-course correction on abstract model for module processing
> 
>         [ Sorry for the *late* response about that... ]
> 
>         * Jean-Jacques Moreau <moreau@crf.canon.fr> [2001-03-21 17:00+0100]
>         > Mark Jones wrote:
>         [ Distinction between header and body ]
>         > > The main distinction as I see it is where the responsibility lies
>         > > for generating responses.  Some handler in some module at the
>         > > destination must take on that responsibility, and having a body
>         > > makes a convenient place to designate that responsibility.
>         >
>         > That's fine. We could do it differently, for example using an
>         > attribute or special URI; this would, in my opinion, simplify the
>         > dispatching machinery (no need to look for a body tag; just use
>         > actors and namespaces everywhere, it will work automatically). But
>         > you are right in pointing out we need to carry out the "body"
>         > semantics, somehow.
> 
>         The whole point about this body/header difference was that carrying
>         out the "body" semantics did not require a different element and that
>         it could be done with a single element and attributes.
> 
>         I still believe that, as Jean-Jacques suggested, it makes more sense
>         to use only one element.
> 
> I like the elegance of a single construct (block), perhaps nested
> inside a grouping elements (Blocks??).  Henrik points out that there
> is a requirement, however, R802, that may lead to some representation
> that physically partitions the message:
> 
>   R802 -- XMLP must also enable processing intermediaries to locate
>           and process XMLP blocks intended for them without processing the
>           entire message.
> 
> I'm not sure what representations might satisfy this.  Also, I am not
> sure how this requirement squares with the possibility of forward
> references using the id/href mechanism.  What if header blocks
> reference body blocks?
> 
> --mark
> 
> Mark Jones
> AT&T Labs
> 
>         --
>         Hugo Haas - W3C
>         mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092