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

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 Tuesday, 7 May 2002 08:53:42 UTC