Issue #203 closed : SOAP Modules

On the April 24th conference call, the WG voted to close issue #203 [1] with the following proposal, which involves edits to the current spec.  Thanks to the editors for making these changes.

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

[In part 1, section 3, add the following sentence to the end of the paragraph
 beginning "The SOAP Processing Model enables SOAP Nodes..."]

"A feature expressed as SOAP headers is known as a SOAP module, and each module
should be specified according to the rules in section 3.2"

[Then the following would be the new section 3.2, pushing MEPs to section 3.3]

<text>

3.2 SOAP Modules

A SOAP module is a feature which is expressed as SOAP headers.

A module specification follows the following rules.  It:

* MUST identify itself with a URI.  This enables the module to be unambiguously
  referenced in description languages or during negotiation.

* MUST clearly and completely specify the content and semantics of the header
  blocks used to implement the behavior in question, including if appropriate
  any modifications to the SOAP Processing model.

* MAY utilize the property conventions defined in section 5 of part 2 in
  describing the functionality that the module provides.  If these conventions
  are followed, the module specification MUST clearly describe the relationship
  between the abstract properties and their representations in the SOAP
  envelope.  Note that it is possible to write a feature specification purely
  in terms of abstract properties, and then write a separate module
  specification which implements that feature, mapping the properties defined
  in the feature spec to SOAP header blocks in the module.

* MUST clearly specify any known interactions with or changes to the
  interpretation of the SOAP body.  Furthermore, it MUST clearly specify any 
  known interactions with or changes to the interpretation of other SOAP 
  features (whether or not those features are themselves modules).
  For example, we can imagine a module which encrypts the body and inserts
  a header containing a checksum and an indication of the encryption mechanism
  used.  The spec for such a module would indicate that the decryption
  algortihm on the receiving side must run *prior* to any other modules which
  rely on the contents of the body.

</text>

--Glen

[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x203

Received on Wednesday, 24 April 2002 17:43:49 UTC