Re: NEW ISSUE: Definition of SOAP 1.2 (and 1.1) modules [i022]

The WG agreed to this text:

   1. Say explicitly in this section that we define a SOAP 1.2 module,  
the SOAP Addressing 1.0 module, and give it a URI:
      http://www.w3.org/YYY/MM/addressing/module

  2. Add a section specific to the SOAP 1.1 binding of Addressing to  
give a URI to this extension (e.g., for WSDL 2.0 description),  
referring to the URI in the SOAP 1.2 section.



On Feb 18, 2005, at 10:43 AM, Hugo Haas wrote:

>
> -=- Description -=-
>
> The SOAP binding defines a SOAP extension, i.e. in the case of SOAP
> 1.2, a SOAP module[1]. The specification does not define it this way.
>
> For WSDL 2.0 description, we should do the same with SOAP 1.1.
>
> -=- Justification -=-
>
> We need to define it in terms mandated by the SOAP 1.2
> specification[1]:
>
>   The term "SOAP module" refers to the specification of the syntax and
>   semantics of one or more SOAP header blocks. A SOAP module realizes  
> zero
>   or more SOAP features. A module specification adheres to the  
> following
>   rules. It:
>
>    1. MUST identify itself with a URI. This enables the module to be
>       unambiguously referenced in description languages or during
>       negotiation.
>
>    2. MUST declare the features provided by a module (see 3.1 SOAP
>       Features).
>
>    3. MUST clearly and completely specify the content and semantics of  
> the
>       SOAP header blocks used to implement the behavior in question,
>       including if appropriate any modifications to the SOAP processing
>       model. The SOAP extensibility model does not limit the extent to
>       which SOAP can be extended. Nor does it prevent extensions from
>       modifying the SOAP processing model from that described in 2.  
> SOAP
>       Processing Model
>
>    4. MAY utilize the property conventions defined in SOAP 1.2 Part 2  
> [SOAP
>       Part 2], section A Convention for Describing Features and  
> Bindings,
>       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  
> specification
>       to SOAP header blocks in the SOAP module.
>
>    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 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.
>
> Because WSDL 2.0 has introduced the concept of SOAP 1.1 modules for
> SOAP 1.1 extension descriptions (see [4]), we should do something
> similar (though simplified) for SOAP 1.1.
>
> -=- Target -=-
>
> SOAP binding (mainly)
> Core (small change)
>
> -=- Proposal -=-
>
> I propose the following changes to the SOAP binding specification,
> unless stated otherwise:
>
> 1. Add a section specific to the SOAP 1.2 binding of Addressing
>
>  1. Say explicitly in this section that we define a SOAP 1.2 module,
>     the SOAP Addressing 1.0 module, and give it a URI:
>     http://www.w3.org/YYY/MM/addressing/soap12/module
>
>  2. List the features that we support:
>         I originally wanted to say that our SOAP 1.2 binding supported  
> the
>     SOAP Action Feature[3], with the
>     http://www.w3.org/2003/05/soap/features/action/Action property
>     being the [action] message addressing property expressed as a
>     <wsa:Action> SOAP header. However, the definition of this feature
>     seems to be specific to underlying protocol bindings.
>
>     Nevertheless, we should say somewhere that, for SOAP 1.2, the
>     value of our [action] message addressing property is the same as
>     http://www.w3.org/2003/05/soap/features/action/Action's.
>
>     More on SOAP 1.2 features in another email.
>
> 2. Add a section specific to the SOAP 1.1 binding of Addressing
>
>  1. Give a URI to this extension for WSDL 2.0 description[4]:
>     http://www.w3.org/YYY/MM/addressing/soap11/module
>
>  2. Say that, when using the HTTP binding, the [action] property
>     ought to be encoded in the request as a SOAP Action header.
>
> 3. Remove the following from Core:
>
>     Finally, if in addition to the [action] property, a SOAP Action
>     URI is encoded in a request, the URI of the SOAP Action MUST be
>     the same as the one specified by the [action] property.
>
>   Not only this is SOAP specific and therefore shouldn't be in Core,
>   but this is SOAP 1.1 over HTTP specific as the SOAP Action Feature
>   in SOAP 1.2 would allow [action] to be expressed in a reply to.
>
> Cheers,
>
> Hugo
>
>  1. http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapmodules
>  3. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#ActionFeature
>  4.  
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-soap11- 
> binding.html?content-type=text/html;%20charset=utf-8#soap11-binding- 
> description
> -- 
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Tuesday, 1 March 2005 20:22:04 UTC