RE: Issue #203 : First draft text

I've revamped this text a little to capture your concerns, Noah, and to attempt
to clarify the feature/module relationship.  It might be nice if there could be
an example in the primer of a feature that had implementations both as part of
a binding and as a module.  Thank you for the comments, please let me know if
this seems better.

[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

> -----Original Message-----
> From: Noah Mendelsohn/Cambridge/IBM 
> [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Thursday, April 11, 2002 4:37 PM
> To: Glen Daniels
> Cc: xml-dist-app@w3.org
> Subject: Re: Issue #203 : First draft text
> 
> 
> Overall I like this a lot.  A couple of minor points:
> 
> * "MUST clearly specify any known interactions with other 
> extensions in terms 
> of
> semantics or sequence."  I think that should be : "MUST 
> clearly specify any known interactions with or changes to the 
> interpretation of the SOAP body.  Furthermore, MUST clearly 
> specify any 
> known interactions with or changes to the interpretation of 
> other SOAP 
> features (whether or not those features are themselves modules)."
> 
> The wording might need a bit of cleanup.  Two points I am 
> trying to make 
> are (1) interactions with the body need to be covered and (2) 
> "extension" 
> is not a word we use in the rec... its features, I think, and 
> we need to 
> cover the features that are headers as well as those that are not.
> 
> * * MAY indicate that the Module functions as an 
> implementation of a SOAP 
> Feature as defined in sec 3 of
>   part 1.   <<= Didn't you define a module as a feature?  Do 
> you mean one that 
> follows the properties convention?  If so, you should refer 
> specifically 
> to the section on property conventions.
> 
> As I say, overall I like this a lot.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
>

Received on Monday, 22 April 2002 19:15:03 UTC