Re: module template draft 2

Thanks David,

I'll try and update the 'must understand mustUnderstand' proposal[1] to use
this template at some point in the next couple of weeks.

Martin

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0115.html


----- Original Message -----
From: "David Clay" <david.clay@oracle.com>
To: <xml-dist-app@w3.org>
Sent: Wednesday, May 09, 2001 7:04 PM
Subject: module template draft 2


> Here is the most recent version of the module template.  It is intended
> to be a blueprint for module definers.  It has been brought up to date
> with current terms used in the glossary and abstract model.
>
> I would like to hear (a) whether this is generally useful and (b) if so,
> how it can be improved.
>
> Thanks.
>
>
>
>
>


----------------------------------------------------------------------------
----


> 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 integrators 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
>     1.. The module name
>     2.. A general written description of the module.
>     3.. 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.  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.
>     4.. The XML namespaces which must be used to qualify schemas,
elements, and attributes defined in the module.
>     5.. The encoding rules to be used when formatting input or output
blocks.  The encoding rules may be embodied in the processing rules for the
module, or may be contained in one or more schemas.
>   2.. Input specification and Processing Rules
>     1.. A list of zero or more input blocks.
>     2.. An XML description of each input block, including its URN
qualification.
>   3.. Output Specification
>     1.. A list of blocks which are affected by the module, including those
that are read, modified, added, or deleted by the module. This list may be
expressed using wild card notation:  for example to indicate that an audit
module should copy all blocks to an audit file.  The list may also be
expressed as a list of references contained in an input block:  for example
to list which blocks are digitally signed.
>     2.. An XML description of each new output block, including its URN
qualification.
>   4.. Processing Rules
>     1.. The encoding rules, if these are embodied in the processing rules
of the module.
>     2.. For each input block,  a written specification of the handler
behavior which is invoked when the block is processed.   The effect of each
element and attribute should be listed.
>     3.. 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.
>     4.. Statement as to whether the block is required (allowing a sender
to format blocks with the "MUST UNDERSTAND" attribute).
>   5.. Exceptions
>     1.. A list of blocks describing standard exceptions which
implementations may throw.  For each exception block, a written description
of the exception condition.
>   6.. Special Binding Considerations
>     1.. Modules should be binding independent.  However, special cases
should be listed here.  An example is the SOAPAction HTTP header element.
>   7.. An example showing a sample document and an explanation of how it
would be processed.
>   8.. 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.
>
> Notes
>
>
>   1.. It is assumed that a handler has access to  all blocks within a
message.  So, for example, an auditing module with zero input blocks could
be invoked to copy entire messages to an audit file.
>   2.. 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 Wednesday, 9 May 2001 15:28:36 UTC