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

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

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Wed, 21 Mar 2001 17:00:39 +0100
Message-ID: <3AB8D027.527294@crf.canon.fr>
To: Mark Jones <jones@research.att.com>
CC: frystyk@microsoft.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org

Thanks for your comments, and sorry for the late response.

Mark Jones wrote:

>         There has been some discussion in the past as to whether we should
>         keep the (somewhat artificial) distinction between headers and body.
>         Are you suggesting that we should keep both, instead of just having
>         blocks?
> This will become zero or more blocks in a header and zero or more
> blocks in a body -- blocks are various referred to as "entries" or
> "parts" in SOAP.


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

>         Also, how would I be able to send two RPCs to an XMLP Receiver via a
>         single XMLP Message if a Message can only carry one body
>         block?
> I don't think having multiple body blocks is a problem,


> but it seems like a single module must be given responsibility for processing them

I disagree. I don't see why we should constraint what Senders can send to Receivers. IMHO,
Senders should be able to send any kind of Blocks to Receivers, *in a single message*.

> and determining a result.

or results (ie, blocks)?

> In the case of header blocks, they can all be individually targeted.
> [...]
>         I am concerned by us automatically removing blocks as soon as they are
>         consummed. I think there are cases where you do want to keep consummed
>         blocks from one intermediary to the next, and I would be reluctant to
>         us having to use the push(pop()) kludge, instead of solving the issue
>         properly. If we really want this functionality, shouldn't we at least
>         make it optional?
> This is the purpose of "none".  Multiple targeted blocks could link
> to a non-targeted block.  Each targeted block gets removed as it
> finds a module capable of processing it, but the non-targeted blocks
> would not be removed.  If the sender wanted to target several
> different intermediaries/modules with the same info, he would include
> separate targeted blocks linking to the common block.  Each targeted
> block will disappear one-by-one, but the untargeted block would survive.

"None" does not answer my concern.

Received on Wednesday, 21 March 2001 11:01:45 UTC

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