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

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 Saturday, 11 May 2002 20:36:34 UTC