- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Sun, 12 May 2002 08:00:53 -0400
- 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 UTC