NEW ISSUE: Definition of SOAP 1.2 (and 1.1) modules

-=- 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/

Received on Friday, 18 February 2005 15:43:21 UTC