W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2001

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

From: Mark A. Jones <jones@research.att.com>
Date: Wed, 07 Mar 2001 09:47:36 -0500
Message-ID: <3AA64A08.4BF26532@research.att.com>
To: "Marc J. Hadley" <marc.hadley@sun.com>
Cc: Ray Denenberg <rden@loc.gov>, Ray Whitmer <rayw@netscape.com>, Marwan Sabbouh <ms@mitre.org>, Henrik Frystyk Nielsen <frystyk@microsoft.com>, Stuart Williams <skw@hplb.hpl.hp.com>, David Fallside <fallside@us.ibm.com>, xml-dist-app@w3.org


"Marc J. Hadley" wrote:

> 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.
>     >
>     >
>     >      [MAJ] I see what you are getting at.  If you
>     >      were to describe this in the specification
>     >      language, you would need to allow module
>     >      application to produce multiple blocks.  You
>     >      would also need a way to refer to them and  to
>     >      add a new message specification to indicate the
>     >      anticipated further processing--  add(M1(A),
>     >      (B,C),  seq { M2(B), M3(C) })??
>     >
>     >      A different tactic would be to use the API for
>     >      modules which you already need for specifying
>     >      specify various actions on the message such as
>     >      generating faults, accessing attachments, etc.
>     >      Adding blocks and associated specifications
>     >      could be done this way.  So inside the execution
>     >      of M1(A), it could issue something like add(
>     >      (B,C),  seq { M2(B), M3(C) }).  This makes the
>     >      specification language simpler, but it obscures
>     >      the transformation that occurred by putting it
>     >      in the module code.
>     >
>     >
>     >
>     >      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)                        application of  module M1 to block A
                  return M1(A)                 application, return value

              2.  M1(M2(A))                    composition
                  return M1(M2(A))             composition, return composed value
                  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   sequence, 2 modules/same block
                  as we both seem to agree
                  that it should be then it

              3.  would need to be put back
                  by M1 before M2 could
                  process it.The alternative   sequence, 1 module/different blocks
                  is that each block can have  sequence, 2 modules/different blocks
                  multiple targets (not        sequence, 2 modules/different
                  currently allowed by the     blocks/reverse order
                  SOAP spec - you can only
                  have one SOAP:actor
                  attribute) but that may be
                  complicating things
                  unnecessarily.
                  [MAJ] In the above spec seq
                  { M1(A), M2(A) }, M1(A)
                  would not remove block A,
                  since there is still an
                  outstanding part of the
                  specification, M2(A) which
                  is still awaiting
                  execution.  As long as the
                  specification contains
                  active references to a
                  block, you need to retain
                  it.  Adding a new block (B)
                  on the fly is another issue
                  -- see above.  If there are
                  no active references to a
                  block then presumably you
                  can eliminate it from the
                  message.
                  seq { M1(A), M1(B) }
                  seq { M1(A), M2(B) }
                  seq { M1(B), M2(A) }
              4.  par { M1(A), M1(B) }         parallel
                  seq {M1(A), return M2(B) }
              5.                               return value from a module application
                  seq {return M1(A), M2(B) }   in a sequence
                  par {M1(A), return M2(B) }
              6.                               return value from a module application
                  par {return M1(A), M2(B) }   in a parallel execution

              7.  seq {return M1(A), return    multiple return values from a sequence
                  M2(B) }

              8.  par {return M1(A), return    multiple return values from a parallel
                  M2(B) }                      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 ?
>     >           [MAJ] Yeah, I believe someone (Henryk?)
>     >           mentioned the idea of a "manifest" one
>     >           time.  The information in a block may be of
>     >           use to various modules along the way.  In
>     >           each use of the block by a module there may
>     >           be constraints on  its ordering
>     >           relationship to other blocks used by that
>     >           module.  Furthermore, if you allow some
>     >           form of composition then you need to be
>     >           able to talk about a module being applied
>     >           to a block(s) produced by applying some
>     >           other module to the block.  There may be a
>     >           block-centric way of describing all of
>     >           those things, but SOAP:actor alone wouldn't
>     >           give it to you.  It seems more intuitive to
>     >           me to think about specifying the process
>     >           apart from the blocks themselves, which are
>     >           simply the data elements.  As a thought
>     >           exercise, you might try capturing this
>     >           specification from the persepctive of the
>     >           blocks:  seq { M1(A), M2(B), M3(M4(B,A)) }
>     >
Received on Wednesday, 7 March 2001 09:46:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:58 GMT