- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 14 Dec 2001 23:14:29 -0500
- To: <xml-dist-app@w3.org>
In my proposed rewrite for issue 101 [1], I suggested a number of issues that should be considered, but I did not at that time correlate them with the existing issues list. Later, I was assigned an action item to correlate my proposed issues with those in the issues list. This note attempts to fulfill that action item. For each of three potential issues mentioned in [1], I propose a disposition below; the first two do not seem to be covered yet, and I propose that two corresponding issues be opened. The third issue identified in my 101 rewrite was resolved by the latest editors' draft. Details on all three follow: * For envelope attributes, we should use the proper XML Schemas simple type terminology, carefully indicate when we are referring to lexical vs. value space, and if a subtype is used (e.g. a boolean that only accepts lexical form "1"), make clear that we are doing so. We do not currently have an issue open on this. I propose that we open such an issue and resolve it along the following lines: we should indicate, probably in chapter 4, that "attributes in the SOAP envelope described by "Part 1: Framework" are are of types from XML Schema: Datatypes (e.g. mustUnderstand is a boolean). Unless otherwise stated, all lexical forms are supported for each such attribute, and lexical forms representing the same value in the XML Schema value space are considered equivalent for purposes of SOAP processing. Thus, the boolean lexical forms "1" and "true" [ref to boolean datatype in the schema spec] are interchangeable. For brevity, text in this specification refers only to one lexical form for each value (e.g. "if the value of mustUnderstand is "true"). Unless otherwise stated, such references implicitly cover all forms corresponding to the same value in the value space. However, when a header block is relayed by an intermediary [see section 2.6], the lexical form of any attributes within that block MUST be preserved. " * Section 2.6 [2] of the latest editors' draft retains the text: "If the SOAP node is a SOAP intermediary, the SOAP message pattern and results of processing (e.g. no fault generated) MAY require that the SOAP message be sent further along the SOAP message path. Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored)." This is known to conflict with the ability to implement encrypting or compressing intermediaries; such intermediaries will presumably remove blocks NOT targeted to that intermediary, and do other seemingly prohibited manipulations. I don't see any issue covering this, and I think one should be opened. * Section 4.2.2: I had mentioned ambiguity regarding the interpretation of a null string on the actor attribute. That seems to have been resolved in the editors' draft, hence no issue needed. [3] [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0027.html [2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#procsoapmsgs [3] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#soapactor ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
Received on Friday, 14 December 2001 23:26:57 UTC