module template draft 1

A module template is used to describe a module for the
following types users:

1.  Module developers who implement the behavior of
the module.  There may be multiple different implementations
of the same module.

2.  Application developers who wish to format and send
documents to be processed by the module.

3.  Application developers who wish to receive and process
documents using an implementation of the module, perhaps in
conjunction with other modules.

A module template consists of the following:

1. General

a.  A URN qualified module template name.

b. A general written description of the module.

c.  A written description of dependencies this module has
on others.  This should be detailed enough to allow an
application developer to assemble modules in a correct
order.  For example, an encryption module must come
after a sender RPC module.

One special dependency is whether the module is a
"terminal module", i.e., one whose completion causes
the XMLP processor to consider the input document
processing to be completed. An example of a terminal
module is one which results in a response,
forward, or one-way message completion.

d. The conformance requirements for the module.
These may consist of descriptive text,  a reference
to test scripts, a reference implementation, or a
test web site.

2.  Input specification

a.  A list of zero or more input blocks or wild cards.

b.  For each input block, an XML description of the
block and a written specification of the behavior
which is invoked when the block is processed.

c.  For each wild card, a written specification of
the behavior which is invoked when a matching block
is present.

d.  The module template definer may specify that a
block or wildcard is required (allowing a sender to
format blocks with the "MUST UNDERSTAND" attribute).

e.  In the special case of zero input blocks, the
module is considered to be optional.  A written
specification of the behavior of the entire module
must be supplied.

f.  In the special case of a wild card containing
"not matching" operator, the module is considered
to be optional, but is only invoked when matching
blocks are not present.

3.  Output Specification

a.  A list of blocks which are modified, added,
or deleted by the module. This list may be expressed
using wild card notation: for example to indicate
that all blocks are modified.

b.  For each block or wild card, a written description
of the output.  If possible, the template should contain
the XML description of output blocks.

c.  A list of blocks describing standard exceptions
which implementations must throw.  For each exception
block, a written description of the exception
condition.


4.  Notes

a.  The module template does not mention number,
order, deployment, or behavior of handlers as we
considered these to be implementation specific.

If this is the case, it may be clearer to omit handlers
from the Abstract Model and talk about "module
implementations" or "module behaviors", or just "modules".

b.  We continue to consider including as part of the template
a module deployment descriptor which could be transformed
into an implementation specific deployment descriptor
(mapping to handlers for an implementation).

Received on Tuesday, 27 March 2001 12:10:31 UTC