Re: module template draft 2

Great work! Comments mingled in below.

Jean-Jacques.

David Clay wrote:

>        1. A written description of dependencies this module has on
>           others.  This should be detailed enough to allow an
>           application integrator to assemble modules in a correct
>           order. [...]
>
How does this relate to Noah's "dependsOn" proposal? Would it be fair
to say that you are thinking at a coarser level of granularity (ie,
modules instead of individual blocks)?

>   1. Input specification and Processing Rules
>        1. A list of zero or more input blocks.
>
Can this always be determined in advance? In particular, I am thinking
of the case where the input is a tree of blocks (ie, a block that
references other blocks, recursively) rather than a mere list, and
where the nature of the tree (eg, the type of the leafs) depends on
some condition (eg, the data contained in the root input block). How
would this be represented in your proposal?

>        1. A list of blocks which are affected by the module,
>           including those that are read, modified, added, or deleted
>           by the module. [...]
>
Currently, SOAP mandates that the blocks processed by a module are
removed from the input message, and that no block is modified. Are you
suggesting that we should be more liberal (this is how I interpret
your "read, modified")?

Also, shouldn't your list include "processed"/"acted upon"?

>        1. In the special case of zero input blocks, the module is
>           considered to be optional. [...]
>
I am not sure the implication holds. For example you could have a
logging module, that does not process any block per say, but logs the
fact that a new message has been received. This module may not be
optional, but it does not process any block.

>        1. Statement as to whether the block is required (allowing a
>           sender to format blocks with the "MUST UNDERSTAND"
>           attribute). [...]
>
I think the spec (currently) says something slightly different: if the
block is there, and it is marked mU, then it must be processed. This
is different from saying that the block is required (which I think we
have no way of expressing, currently).

>        1. A list of blocks describing standard exceptions which
>           implementations may throw.  For each exception block, a
>           written description of the exception condition. [...]
>
Do you think that we should allow multiple exceptions to be returned
as a result of a signle message?

Jean-Jacques.

Received on Friday, 11 May 2001 08:27:56 UTC