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

Thanks for the comments.  As I mentioned in the AM meeting, I will be
updating this to reflect the glossary, but here are some quick responses.

	Date: Thu, 15 Mar 2001 17:44:34 +0100
	From: "Jean-Jacques Moreau" <moreau@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
	Subject: Re: mid-course correction on abstract model for module processing

	Mark,

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

	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
and determining a result.  In the case of header blocks, they can all
be individually targeted.

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

I think the transport level needs to have a way of physically
identifying the host, since it has to eventually get the bits
to some computational engine.  The actor URI's on the other hand
are really naming either default or particular functionality
at the site.  They are really URN's IMHO.

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

Here's how I think about the dispatching rules.

(1) Some actors are like "locations":

  <m:foo xmlns:m="some-URI"  XMLP-ENV:actor="some-place-URI"> ... </m:foo>

  Here you think of the actor as a spce where the processor lives.
  SOAP has a predefined URI for the "next" place, for example.
  It could also be a URL (but probably not) or another means of describing a place.
  In SOAP, the application/processor makes the handler dispatch
  presumably based on the m:foo tag.  In XMLP, we seem to be taking the
  view that modules know the rules, so you would think of
  "some-place-URI" as a default module for the place that knew how to
  select a handler and do the dispatch.


(2) Actors that are "modules":

  <m:foo xmlns:m="some-URI"  XMLP-ENV:actor="some-module-URI"> ... </m:foo>

  This seems to be the natural case to me.  The module
  ("some-module-URI") knows about the block types (such as m:foo)
  in its sphere of influence and it determines what handler to
  dispatch for m:foo, whether to treat it as RPC, etc.
  In the general, non-RPC case, a single handler
  may work on many different types of blocks.

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

Generally, yes, but see above.

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

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.

	>      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 currently see the simplest model as distinguishing between (1) a real
fault (no point in going on), and (2) not that serious, continue.  In
case (2), a block can be inserted into the message to reflect the
issue that arose and the response that eventually gets generated can
incorporate it if desired.


	I hope this helps,

	Jean-Jacques.

Thanks...

Mark Jones

Received on Thursday, 15 March 2001 15:27:23 UTC