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

Here are some clarifications and further questions/comments.

Regards,
Marc.

      An Abstract Model for Module Processing
      Concepts 
        Concept 4
        Can an evaluation result in multiple response blocks ?
      I would certainly advocate that.  This is the intention in a specification such as seq { return M1(A), return M2(B) }.  You want the responses from both module applications to be returned. 

      [MJH] To clarify my question, I meant could a single operation, e.g. M1(A) give rise to more than one new block being added to the message rather than being returned to the originator ? Specifically I am thinking of the case where M1(A) gives rise to two or more further blocks: B, C, ... which may then be consumed by later modapps.
      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 ? 
            [MAJ] No, M1(A) is not necessarily equal to A.  Since no return value was indicated, it presumably is being executed for side-effect on the world somehow, and perhaps is in the seq since it is logically prior to the M2(A) execution. 
            [MJH] I should have been clearer in my question, I am thinking of a specific case of the example I gave above where M1(A) -> leads to two new blocks: A (identical to the input block) and B (some new block). The reason I wanted to draw this point out is that if A is removed by M1 as we both seem to agree that it should be then it would need to be put back by M1 before M2 could process it.
            The alternative is that each block can have multiple targets (not currently allowed by the SOAP spec - you can only have one SOAP:actor attribute) but that may be complicating things unnecessarily.
            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 targeted 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 ?
        [MAJ] The invocation order is determined by the processing specification, not by the order of appearance of blocks.  For example, seq {M1(A), M2(), M3(B)}.  M2 gets invoked after M1(A), that's all.  It is just 0-ary in terms of its arguments. 
        [MJH] I think we are coming at this from different directions, I was thinking of the SOAP case where targeting is provided by the SOAP:actor attribute on a header. If I understand correctly, you seem to be suggesting a completely separate "processing specification" contained within the message that ties modapps to blocks in a message ?