Two issues to be opened relating to my rewrite for Issue 101 (and one more already resolved)

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