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: Thu, 15 Mar 2001 17:44:34 +0100
Message-ID: <3AB0F171.9B448FC3@crf.canon.fr>
To: "Mark A. Jones" <jones@research.att.com>
CC: Henrik Frystyk Nielsen <frystyk@microsoft.com>, Stuart Williams <skw@hplb.hpl.hp.com>, John Ibbotson <john_ibbotson@uk.ibm.com>, Krishna Sankar <ksankar@cisco.com>, Lynne Thompson <Lynne.Thompson@unisys.com>, Marc Hadley <marc.hadley@uk.sun.com>, Martin Gudgin <marting@develop.com>, Nick Smilonich <nick.smilonich@unisys.com>, Oisin Hurley <ohurley@iona.com>, Scott Isaacson <SISAACSON@novell.com>, Yves Lafon <ylafon@w3.org>, xml-dist-app@w3.org

Thanks for the rewriting and the hard work, although I must admit I
preferred the original version. :(

"Mark A. Jones" wrote:

>   1. An XML Protocol Message consists of zero or more header blocks
>      and one body block. [...]
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

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?

>   1. Each header has an optional associated id (identifier), an
>      optional actor and an optional mustUnderstand flag.  The body
>      has an optional associated id (identifier) and an optional
>      actor.  The body must be understood.  The id is an ID that
>      identifies the block for the purposes of reference by other
>      blocks.  The actor is a URI used by the XML Protocol Processor
>      for determining which module to apply to the block. [...]
Noah has suggested (cf issue 41) that we use two different URIs, one
for physically identifying the host, one for the identifying the
service. Wouldn't this have an impact on the actor attribute?

>   1. There are reserved actor URI's with special significance:
>        http://.../none       // matches no module (i.e., an
>      untargeted header)
>        http://.../next       // matches a default module at the next
>      processor
>        http://.../final      // matches a default module at the
>      final processor
>        http://.../body       // matches the module selected at the
>      final processor (can be used as a target for headers)
>      [...]
Don't we need some lower level of granularity in these URIs, so we can
address, for example, a particular handler?

Also, shouldn't the URIs be HTTP agnostic, if we claim we are
transport independent?

>   1. When a header is selected for processing by a module at an
>      intermediary, the header is removed from the envelope.  [...]
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?

>      The processing of a header may result in a fault or a
>      successful evaluation.  A fault terminates processing and
>      causes a return message containing the fault to be generated if
>      a return path is available. [...]
Does a fault terminate all processing, including forwarding to the
next hop; or does it only terminate processing at the current node,
with forwarding still happening? The text probably requires some
amount of clarification.

I hope this helps,

Received on Thursday, 15 March 2001 11:45:46 UTC

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