- From: Mark A. Jones <jones@research.att.com>
- Date: Wed, 07 Mar 2001 09:47:36 -0500
- 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
- Message-ID: <3AA64A08.4BF26532@research.att.com>
"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 UTC