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

An Abstract Model for Module ApplicationThis looks like a good start, I have a few questions and comments that are interspersed in the text below and preceded by [MJH].
  An Abstract Model for Module Processing
  Concepts
    1.. An XML Protocol Message consists of one or more blocks.
    [MJH] Do we need to differentiate between the "body" of the message and blocks targetted at module processors (or XML Protocol Handlers to use the naming in the current abstract model document) ? We could just treat the message body as a special case of a block that is targetted at the final module processor ?

    2.. The XML Protocol Message specifies a set of module applications and the order in which they will be carried out by the processor.  The message may also specify a set of RPC conventions that influence the module application.
    [MJH] This is impacted by the ongoing discussion of the routing capabilities of XML Protocol. If explicit routing and targetting are supported (i.e. this XMLP Handler at this XMLP Node - again using the naming in the abstract model document) then there should be no problem, although the order might result in one Node being visited multiple times. If hop-by-hop routing (i.e. each XMLP processor forwards messages according to some internal rules or configuration) is supported then the order of processing could only be guaranteed if all Handlers are located on the same node. 

    Consider the following example: the message contains 3 blocks targetted at Handlers A, B and C in that order. A and C are located at node 1 whilst B is located at node 2.
    Using explicit routing the message would be processed in the following order: A[1], B[2], C[1].
    Using hop-by-hop routing the message would be processed in the following order: A[1], C[1], B[2].
    Note that the order of processing is only important in the case where Handlers are composed. Personally I would prefer the KISS approach of hop-by-hop routing and leave it up to the application designer to ensure that order critical Handlers are co-located.

    3.. A module application may result in a fault or a successful evaluation.

    4.. The result of a successful evaluation may be void or a response block.
    [MJH] Does this imply that processed blocks are removed from the message ? Should this be stated explicitly as in section 4.2.2 of the SOAP 1.1 specification: "... a recipient receiving a header element MUST NOT forward that header element to the next application in the SOAP message path". As in SOAP, the response block may be very similar (identical) to the processed block, but for the purposes of discussion may be treated as a new block.

    Can an evaluation result in multiple response blocks ?

    5.. The specification of the module application should indicate whether the response block is to be included in a return message.

    6.. A module may be applied to more than one block (in a single evaluation of the module).

    7.. The response block block generated by one module application may also serve as an input for another module application.  This permits the composition of services.  For example, one module application might do decompression, with its response block fed to a module that did decryption, with its response block fed to an application-specific module.

    8.. The ordering among module evaluations could be total or partial, permitting parallelism if the processor is capable of it.

  Semantic Operations
  The following grammar defines an abstract syntax for the semantic operations of block evaluation that satisfies and instantiates the above concepts.  It is emphasized that this is an abstract syntax for the purpose of defining a notation for discussing semantics and defining an abstract  module processing model; the concrete syntax actually used in XML Protocol messages may differ.  

    1.. Module application -- a module is applied to one or more blocks and can produce a resulting block
    Composition of module applications -- a module is applied to blocks produced by module applications

    modname ::= < primitive modname syntax >
    block   ::= < primitive block syntax >
    modarg  ::= modapp | block
    modapp  ::= modname "(" modarg ["," modarg]* ")"

    2.. Return values -- specifying a return value from a module application

    modexpr ::= return modapp | modapp

    3.. Sequential application -- the sequential execution of expressions
    Parallel application -- the parallel execution of expressions

    seqexpr ::= seq "{" expr ["," expr]* "}"
    parexpr ::= par "{" expr ["," expr]* "}"
    expr    ::= modexpr | seqexpr | parexpr



  Examples of Abstract Module Operations
  [These expressions could be viewed graphically, analogous to the diagram showing handler processing in Figure 5.2.]

        1. M1(A)
        return M1(A) application of  module M1 to block A
        application, return value 
        2. M1(M2(A))
        return M1(M2(A)) composition
        composition, return composed value 
        3. seq { M1(A), M2(A) }
        [MJH] Given my question about concept 4 above, should this just be another case of composition M2(M1(A)) where M1(A) = A ?
        seq { M1(A), M1(B) }
        seq { M1(A), M2(B) }
        seq { M1(B), M2(A) } sequence, 2 modules/same block




        sequence, 1 module/different blocks
        sequence, 2 modules/different blocks
        sequence, 2 modules/different blocks/reverse order 
        4. par { M1(A), M1(B) } parallel 
        5. seq {M1(A), return M2(B) }
        seq {return M1(A), M2(B) } return value from a module application in a sequence 
        6. par {M1(A), return M2(B) }
        par {return M1(A), M2(B) } return value from a module application in a parallel execution 
        7. seq {return M1(A), return M2(B) } multiple return values from a sequence 
        8. par {return M1(A), return M2(B) } multiple return values from a parallel execution 



  Issues
    1.. Should a module application be allowed to apply to zero or more modargs?   Maybe the module application is triggered purely for side-effect.
    [MJH] If there are no blocks targetted for a given modapp (Handler) how would the XMLP application/processor know to invoke it ? This could be a configuration setting in the application/processor I suppose ?

    2.. Should we allow an XML Protocol Message to contain zero or more blocks?  The message could exist purely to trigger module applications for their side-effects without any message blocks. (This assumes that modules can be applied to zero modargs.) 
    [MJH] If we provide a mechanism for triggering non-targetted modargs then I see no reason why not.

    3.. Should a seq or par be allowed to contain zero or more expressions?  They presumably would have no computational effect, but would be harmless.

    4.. Should  return be implicit?  An alternative concept would be to have every module application that is not contained inside another module application return a value (which may be void) for the reply.  Having an explicit  return allows modules to produce a value, but not always require that it be returned.  You can think of return as a "module" that explicitly directs its input (the output of a module application) into the reply message.

    5.. Will we ever want to do something like this?  (not allowed by current abstract syntax)
    M1(return M2(A))                                                    composition, but only return value of M2(A)

    6.. How would implementations handle multiple parallel returns without unbounded buffering since the return wire format is serialized? (allowed by the current abstract syntax -- should it be?)
    par {return M1(A),(return M2(B)}            parallel, multiple return values 
    [MJH] This could result in multiple return messages as one solution.