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

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

From: christopher ferris <chris.ferris@east.sun.com>
Date: Tue, 03 Apr 2001 09:41:10 -0400
Message-ID: <3AC9D2F6.AE40A44A@east.sun.com>
To: Mark Jones <jones@research.att.com>
CC: hugo@w3.org, xml-dist-app@w3.org

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...



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
Received on Tuesday, 3 April 2001 09:44:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC