W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2002

Re: review of SOAP 1.2 Part 1 diffs from 11-Apr w/r/t assertions doc

From: Christopher Ferris <chris.ferris@sun.com>
Date: Sun, 12 May 2002 08:00:53 -0400
Message-ID: <3CDE5975.7040805@sun.com>
CC: xml-dist-app@w3.org
the one you sent out a few days ago in [1]

Cheers,

Chris

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002May/0048.html

Anish Karmarkar wrote:

> Chris,
> 
> Thanks for the sending the diffs.
> 
> Could you please let me know which version of the conformance doc you
> used?
> 
> Thanks.
> 
> -Anish
> --
> 
> Christopher Ferris wrote:
> 
>>I took an AI in last week's telcon to review the current
>>SOAP editor's snapshot (3-May) to determine any impact on the
>>assertions and testcases document which is based on the
>>11-April drafts.
>>
>>Here are my findings w/r/t SOAP 1.2 Part 1. I will follow
>>with a separate analysis for Part 2 as I get time.
>>
>>Cheers,
>>
>>Chris
>>
>>assertion #8, text from spec has changed
>>assertion #12, text from spec has changed
>>assertion #16, text from spec has changed
>>assertion #29, text from spec has changed
>>
>>SOAP1.2 Part 1 Sect 3.2 introduces new assertions:
>>
>>"3.2 SOAP Modules
>>
>>A SOAP module is a feature which is expressed as SOAP headers.
>>
>>A module specification follows 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 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.
>>    3.
>>
>>       MAY utilize the property conventions defined in Part 2 [1], 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 module.
>>    4.
>>
>>       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 specification for such a module would
>>indicate that the decryption algorithm on the receiving side must run prior to any other modules
>>which rely on the contents of the body."
>>
>>assertion #29, text from spec has changed
>>
>>new assertion in section 4.2:
>>
>>"Bindings MAY provide for streaming when processing messages. That is, SOAP nodes MAY begin
>>processing a received SOAP message as soon as the necessary information is available. SOAP
>>processing is specified in terms of Envelope XML infosets (see 5. SOAP Message Construct). Although
>>streaming SOAP receivers will acquire such Infosets incrementally, SOAP processing MUST yield
>>results identical to those that would have been achieved if the entire SOAP envelope were available
>>prior to the start of processing. For example, as provided in 2.6 Processing SOAP Messages,
>>identification of targeted headers blocks, and checking of all mustUnderstand attributes must be
>>done before successful processing can proceed. Depending on the representation used for the Infoset,
>>and the order in which it is transmitted, this rule may limit the degree to which streaming can be
>>achieved."
>>
>>assertion #63 text from spec has changed as have the child eii names of
>>the Fault element
>>
>>assertion #64 text from spec has changed
>>
>>assertion #65 text from spec has changed
>>
>>new assertion in SOAP1.2 Part 1 sect 5.4:
>>
>>"When generating a fault, SOAP senders MUST NOT include additional element
>>information items in the SOAP Body . A message whose Body contains a Fault
>>plus additional element information items has no SOAP-defined semantics."
>>
>>assertion #66 text from spec has changed
>>
>>assertion #67 text from spec has changed
>>
>>assertion #68 text from spec has changed
>>
>>assertion #69 text from spec has changed faultString is now Reason
>>
>>assertion #70 text from spec has changed faultString is now Reason
>>
>>assertion #71 text from spec has changed
>>
>>assertion #73 text from spec has changed
>>
>>assertion #74 text from spec has changed
>>
>>assertion #75 text from spec has changed
>>
>>assertion #78 text from spec has changed
>>
> 
Received on Sunday, 12 May 2002 08:03:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT