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

	From skw@hplb.hpl.hp.com Thu Mar 22 11:46 EST 2001
	Delivered-To: jones@research.att.com
	From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
	To: "'Jean-Jacques Moreau'" <moreau@crf.canon.fr>,
	        Mark Jones <jones@research.att.com>
	Cc: frystyk@microsoft.com, xml-dist-app@w3.org
	Subject: RE: mid-course correction on abstract model for module processing
	Date: Thu, 22 Mar 2001 16:46:25 -0000
	MIME-Version: 1.0

	Mark,

	Quick question... you mention untargetted blocks that don't get removed by
	intermediary processing en-route. However, my understanding of SOAP is that
	blocks (header entries) without an explicit target are implictly targetted
	at the ultimate recipient. If that is the model we carry over, how would we
	designated a block as 'untargetted' rather than at the default target (the
	ultimate recipient)?

Use the actor URI in a similar manner to its use to denote the "next"
processor:  http://.../none


	The abstract question is there a clear conceptual distinction between
	untargetted and targetted at a default target. The practical question (which
	actually I'm less concerned about) is how would be denote the difference
	(syntax/angle bracket question).

The semantics is simple.  The block is available for reference by
other blocks, but isn't otherwise going to be dispatched to a
particular handler by the top level processor algorithm.

SOAP apparently lets blocks reference other blocks, whether explicitly
or implicitly targetted.  If explicitly targetted at an intermediary,
it gets a little tricky since you would have to make sure that the
block was targeted at the LAST such intermediary (if that can be known
in advance).  By implicitly targetting them at the ultimate recipient
they are available at all intermediaries and never removed.  The
downside is that they will be targetted at the ultimate recipient
whether it wants to see them or not.  The "none" URI just provides a
cleaner construct for exactly saying "this block is targetted at no
processor".

--mark

	Thanks,

	Stuart

	> -----Original Message-----
	> From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr]
	> Sent: 22 March 2001 16:31
	> To: Mark Jones
	> Cc: frystyk@microsoft.com; skw@hplb.hpl.hp.com; xml-dist-app@w3.org
	> Subject: Re: mid-course correction on abstract model for module
	> processing
	> 
	> 
	> Mark Jones wrote:
	> 
	> > I am now leaning toward a model where any of the handlers 
	> that execute
	> > at the destination can contribute blocks for the return message.  If
	> > we furthermore avoid the header/body distinction then you don't even
	> > have a buffering/serialization problem if the handlers execute
	> > serially.  Simpler and better...  :-)
	> 
	> That sounds great!
	> 
	> >         > 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.
	> >
	> > I'm not sure why not.  [It is not push(pop()).]  What is 
	> the use case
	> > that you have in mind?
	> 
	> I have just been rereading your message with a fresh mind, 
	> and I think the solution you propose would
	> satisfy my needs, albeit at the expense of extra blocks.
	> 
	> I am still wondering, though, why we require that consummed 
	> blocks are not forwarded further. (It
	> sounds like it would require Processors to do a lot of XML 
	> cut-and-paste, which may be expensive.)
	> Anyone with a good answer? Henrik?
	> 
	> Jean-Jacques.
	> 
	>

Received on Thursday, 22 March 2001 12:06:32 UTC