- From: Glen Daniels <gdaniels@macromedia.com>
- Date: Wed, 10 Apr 2002 20:07:27 -0400
- To: <xml-dist-app@w3.org>
Here's a first cut at some text for the spec which moves towards resolving issue 203 [1]. IN SECTION 3, PART 1: 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 X" (where X is a new section somewhere) IN SECTION X: "A SOAP Module is a well-specified set of semantic extensions to the core protocol, expressed as SOAP headers. A Module specification: * 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. * MUST clearly specify any known interactions with other extensions in terms of semantics or sequence. 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 must indicate that the decryption algortihm on the receiving side must run prior to any Modules which rely on the contents of the body. * MAY indicate that the Module functions as an implementation of a SOAP Feature as defined in sec 3 of part 1. In this case, the spec must also clearly specify, if appropriate, the relationships between any abstract properties defined in the feature spec (as described in sec 5 of part 2) and concrete instantiations in the SOAP envelope." I think this needs some wordsmithing (I'm sending this from the middle of a WG meeting), but it's a start. Comments / issues / questions appreciated! --Glen
Received on Wednesday, 10 April 2002 23:32:09 UTC