W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

Re: Issue #203 : First draft text

From: Christopher Ferris <chris.ferris@sun.com>
Date: Thu, 11 Apr 2002 09:17:20 -0400
Message-ID: <3CB58CE0.9030302@sun.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT