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

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

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

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 11:46:41 UTC