Re: Proposal for clarifying relationship between SOAP modules and features

I like this on the whole, but I have a couple of questions about where 
we're headed:

* In JJM's other note he reiterates that a module can either refer to a 
separate feature, or implicitly define the feature inline with the module 
spec.  Fine, but what concerns me is that we need a clean story on the URI 
naming of these thinkgs: 

- I very much want it to be the case that: every feature, regardless of 
whether defined separately or in a module spec, is to be named by a URI. 
This is very important so that WSDL can evolve in a direction of defining 
services that are supported iff the binding used supports some set of 
features (typically not modules, as it is often the business of the 
binding to decide whether to use a module or some other means to implement 
the feature.)

- I am neutral on whether modules should also be named with URIs, but I do 
want the rec to be clear.  If the answer is yes, then we need to be clear 
that a module that defines its own feature inline in its spec MUST provide 
URIs to name each, and perhaps provide some guidance as to whether these 
should in general be different or may be the same URI.

* Henrik's proposal says:

>> "5. 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 and SOAP modules. For example, we
>> can imagine a module which encrypts the SOAP body and
>> inserts a SOAP header block containing a checksum and
>> an indication of the encryption mechanism used. The
>> specification for such a module would indicate that the
>> decryption algorithm on the receiving side is to be run
>> prior to any other modules which rely on the contents
>> of the SOAP body."

I think the example mixes up digital signatures and encryption.  It's a 
signature that's more likely to be a checksum of some (sum?) sort.   So, 
how about:

"5. 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 and SOAP modules. For example, we
can imagine a module which encrypts and removes the
SOAP body, inserting instead a SOAP header block
containing the encrypted information and an indication
of the encryption mechanism used. The specification for
such a module would indicate that a decryption
algorithm on the receiving side is to be used to
reconstruct the body prior to invoking other modules
that rely on the contents of the body."

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Jean-Jacques Moreau" <moreau@crf.canon.fr>
Sent by: xml-dist-app-request@w3.org
11/07/02 04:08 AM

 
        To:     Henrik Frystyk Nielsen <henrikn@microsoft.com>
        cc:     xml-dist-app@w3.org, noah_mendelsohn@us.ibm.com
        Subject:        Re: Proposal for clarifying relationship between SOAP modules and features
Categories: 
 





Henrik Frystyk Nielsen wrote:
> And to shorten the second paragraph as follows:
> 
> "The term 'SOAP module' refers to the specification of the syntax and
> semantics of one or more SOAP header blocks. A module specification
> adheres to the following rules. It:..."

I'd like to suggest the following friendly amendment:

<friendlyAmendment>
*A* SOAP Module refers to the *combined* specification of the 
syntax and semantics of one or more SOAP header blocks. *A SOAP 
module implements one or more SOAP features.* A module 
specification adheres to the following rules. It:...
</friendlyAmendment>

I'd also suggest that we lift the above definition (or a revised 
version thereof) and add it to the glossary. There is currently 
no definition for SOAP Module!

> And in list item 5 replace "(whether or not those features are
> themselves modules)" with
> "and SOAP modules" so that the item reads:
> 
> "5. 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 and SOAP modules. [...]"

I think this adds confusion rather than clarity, since a module 
is an implementation of a feature. I don't think we need the 
extra "add SOAP modules". I'd suggest ending the sentence with 
just "of other SOAP features."

+1 to your other changes.

Jean-Jacques.

Received on Friday, 8 November 2002 11:57:47 UTC