- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Thu, 11 Apr 2002 09:17:20 -0400
- To: Jean-Jacques Moreau <moreau@crf.canon.fr>
- CC: Glen Daniels <gdaniels@macromedia.com>, xml-dist-app@w3.org
+1 Jean-Jacques Moreau wrote: > +1. Presumably, X woud be inserted between Section 3.1 and Section 3.2 [1]. > > Jean-Jacques. > > [1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#extensibility > > Glen Daniels wrote: > > >>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 Thursday, 11 April 2002 09:18:27 UTC