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.

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).