Re: Issue #203 : First draft text

+1 for the primer example.
+1 for the revised text.

So modules are back formally... after a 1.5 year of disgrace! (That's fine; just
making this explicit.)

Jean-Jacques.

Glen Daniels wrote:

> 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 Tuesday, 23 April 2002 04:11:36 UTC