Re: Abstract Model contribution for module processing and also for attachments

"Williams, Stuart" wrote:

> Hi Mark,
>
> Firstly, I've added you the my mailing list of subgroup members so you'll
> get any postings.
>
> The module processing model that you propose looks interesting. I've got a
> couple of questions:
>
> 1) How does the term 'module application' relate to the terms 'XML protocol
> application' and 'XML protocol handler'?

By 'module application' (noun phrase) or 'applying a module ("to one or more
related XML Protocol Blocks")', I believe it maps pretty well to a single
execution of an 'XML protocol handler'.  The issue would be one of granularity
of mapping for the dispatch.  My understanding of the AM terminology was an XML
Protocol Application is at a semantic level of an entire node -- e.g., "An XML
Protocol Intermediary is an XML Protocol Application."  An XML Protocol Module
seems to be the term for a related set of XML Protocol Handlers.  My module
applications (M1, M2) are similar to function applications in a programming
language, but I guess the real question is:

     Who specifies the processing flow?  I have assumed that the sending
     XMLP application would specify the composite processing flow, just as
     it is might make an RPC call. It knows what it wants done and it knows
     how it constructed the blocks in the message.  I had assumed that the
     sender's processing specification would target blocks to Modules
     (specific sequentiality, desired results, etc.) and not a specific
     Handler in a module.  The Module would determine the handler given its
     rules and the kinds of blocks that it was given.  So the final
     dereferencing to a handler and any other processing rules (RPC?) are
     managed at the receiver.  The perspective in my proposal was more from
     the sender who would include such a specification (e.g., seq { M1(A),
     return M2(B) }) in a manifest in the message along with the blocks
     being sent.

> I can see how what you propose give us an algebraic way for expressing
> structure like those shown in Fig 5.2[1]. Have you any thoughts on
> constraints on parallel processing? eg. practically I think it hard to
> imagine a parallel construct extending over multiple intermediaries.

Issue 6 anticipated one issue with parallelism even without intermediaries.  I
haven't thought through the issues with intermediaries yet, but clearly there is
more to say.  For one thing, with composition you have to process a contained
Module before any containing ones.  If an intermediary only partially evaluates
an expression, say a contained Module, it needs to add a block containing the
result and substitute that block in the specification (sort of like replacing a
function call with a variable that represents its value) accordingly so that the
remainder of the specification can be computed by later nodes.

> 3) You mention the possibility that module processing might generate a fault
> (Concept list #3). Have you any thought on fault propagation? Do they
> terminate the processing of a message? Do they feed-forward toward the
> intended recipient of the processed message or do they get returned toward
> the originator of the message?

Faults are one of those things in programming languages that generally require
some coordination between callers and callees.  I haven't thought all this
through completely, but one option would be:

   * Default to some reasonable behavior for the outermost module applications
     such as 'fault back toward the originator'.
   * Allow modules to 'catch' the faults of contained modules (if they so
     choose), so that you can effectively specify application-specific fault
     propagation strategies.  E.g., M1-Error-Handler(M1(A)) is the composition
     of two modules.  M1 is a general module that typically does something
     interesting but sometimes generates some known class of faults.
     M1-Error-Handler is another module that could be contributed by a
     particular application that knows how it wants to deal with those faults --
     propagate them forward or backward, suppress them, etc.  If M1 doesn't
     generate a fault then M1-Error-Handler presumably just passes on the block
     produced by M1.

>
> 4) Does the syntactic ordering of 'result' blocks inserted into a message
> have any significance and is there a need to model that?

The simplest model is just a streaming model, like writing to stdout in a
programming language.  In a sequence, the results would presumably be inserted
in the order that the modules executed.  Issue 6 acknowledged, however, that you
would have to effectively mutex the result reporting in a parallel construct
since we are serializing the result on the wire.  Blocking would destroy the
parallelism; buffering would be impractical if the results were large.  Marc
Hadley suggested maybe having parallel constructs generate multiple return
messages, but I don't know where that might lead.

>
> On the attachment model in the second part of the document:
>
> 1) In concepts item 2 would it be clearer to refer to message context rather
> than processing context?

That would be a fine emendation.  We might want to consider the possibility that
a module could dynamically add another attachment (as well as a referring block)
to the context, but you could still call it the message context.

Mark

Mark A. Jones
AT&T Labs -- Research

>
>
> Best regards and many thanks,
>
> Stuart
>
> [1]
> http://www.w3.org/2000/xp/Group/1/02/16-abstract-model/XMLProtocolAMG.html/#
> Fig5.2
>
> > -----Original Message-----
> > From: Mark A. Jones [mailto:jones@research.att.com]
> > Sent: 05 March 2001 18:33
> > To: Ray Denenberg; Ray Whitmer; Marwan Sabbouh; Henrik
> > Frystyk Nielsen;
> > Stuart Williams; David Fallside
> > Cc: xml-dist-app@w3.org
> > Subject: Abstract Model contribution for module processing
> > and also for
> > attachments
> >
> >
> > [David, Stuart:  I would like to be added to the Abstract Model
> > subgroup.]
> >
> > [Stuart:  The attachment here reflects some thinking that I have been
> > doing on an Abstract Model specification for Module
> > Processing.  It also
> > contains some ideas on Attachments.  I would like to solicit general
> > discussion and offer them as starting points for inclusion in the
> > Abstract Model document.]
> >
> > [Ray D., Ray W., Mahwan, Henrik:  For me to think clearly about how to
> > consider RPC, I needed to first attempt to clarify some kind
> > of abstract
> > model for Module Processing first.  This is what you'll find in the
> > attachment.  It makes a small reference to RPC.  If you like the
> > framework, then maybe we can clarify what RPC is in this context.  It
> > seems like it is primarily a convention for how to interpret
> > the markup
> > in a block and how to interpret the return result.]
> >
> >