Proposed text for issues rec20 and rec22

I took an action item "Draft SOAP 1.2 errata to fix rec20 (and rec22)"
which basically has to do with non XML 1.x content in SOAP infosets.  As I
am on vacation this week and on a slow link, it is difficult to refine
these proposals as thoroughly as I normally would, but I hope this is
enough to get you all started.  There's a less than 50/50 chance of my
being on the call tomorrow.  I have only attempted part 1.  Someone should
look to see whether anything is needed in part 2?  I don't think so, but
didn't check this evening.

As background, the issue is that we found that nowhere in the XML Infoset
recommendation does it say that content must correspond to >any< known
version of XML, much less XML 1.0.  Thus, nulls are allowed in character
children, strange chars in XML names, etc.  My action is to propose
specification text that could serve as an erratum to SOAP 1.2.  All
references are to sections in our current editors' draft [1].

--------
Section 4.2
<current>
As described in 5. SOAP Message Construct, each SOAP message is specified
as an XML infoset that consists of a document information item with exactly
one child: the SOAP Envelope element information item. Therefore, the
minimum responsibility of a binding in transmitting a message is to specify
the means by which the SOAP message infoset is transferred to and
reconstituted by the binding at the receiving SOAP node and to specify the
manner in which the transmission of the envelope is effected using the
facilities of the underlying protocol.

The binding framework does not require that every binding use the XML 1.0
[XML 1.0] serialization as the "on the wire" representation of the XML
infoset; compressed, encrypted, fragmented representations and so on can be
used if appropriate. A binding, if using XML 1.0 serialization of the XML
infoset, MAY mandate that a particular character encoding or set of
encodings be used.
</current>

<proposed>
As described in 5. SOAP Message Construct, each SOAP message is specified
as an XML infoset that consists of a document information item with exactly
one child: the SOAP Envelope element information item. Therefore, the
minimum responsibility of a binding in transmitting a message is to specify
the means by which the SOAP message infoset is transferred to and
reconstituted by the binding at the receiving SOAP node and to specify the
manner in which the transmission of the envelope is effected using the
facilities of the underlying protocol.

>Bindings MUST provide for transmission of SOAP message Infosets that are
serializable as XML 1.0, and MAY provide for transmission of SOAP message
Infosets that are representable using other W3C recommendation-level
versions of XML (e.g. [link to XML 1.1]).  Bindings MUST reflect a
binding-dependent fault {see below...maybe should be standard fault?} if
the message to be sent depends on a version of XML not supported by the
binding.<

The binding framework does not require that every binding use >an XML
serialization< as the "on the wire" representation of the XML infoset;
compressed, encrypted, fragmented representations and so on can be used if
appropriate. A binding, if using >an XML< serialization of the XML infoset,
MAY mandate that a particular character encoding or set of encodings be
used.
</proposed>

--------
Section 5.0

<current>
A SOAP message is specified as an XML infoset that consists of a document
information item with exactly one member in its [children] property, which
MUST be the SOAP Envelope element information item (see 5.1 SOAP Envelope).
This element information item is also the value of the [document element]
property. The [notations] and [unparsed entities] properties are both
empty. The [base URI], [character encoding scheme] and [version] properties
can have any legal value. The [standalone] property either has a value of
"yes" or has no value.

The XML infoset of a SOAP message MUST NOT contain a document type
declaration information item.

...
</current>

<proposed>
A SOAP message is specified as an XML infoset that consists of a document
information item with exactly one member in its [children] property, which
MUST be the SOAP Envelope element information item (see 5.1 SOAP Envelope).
This element information item is also the value of the [document element]
property. The [notations] and [unparsed entities] properties are both
empty. The [base URI], [character encoding scheme] and [version] properties
can have any legal value. The [standalone] property either has a value of
"yes" or has no value.

>The Infoset Recommendation [link to Infoset] allows for content not
directly serializable using XML;  for example, the character #x0 is not
prohibited in the Infoset, but is disallowed in XML.  The XML Infoset of a
SOAP Message MUST correspond to an XML serialization using some W3C
Recommendation-level version of XML.  At the time of this writing, the XML
recommendations are [ref to XML 1.0 version 2 or 3, ref to XML 1.1], but
future XML Recommendations, if any, MAY also be used for SOAP envelopes.

Note that some protocol bindings may be incapable of transmitting messages
corresponding to versions of XML later than 1.0 [link to revised text from
above for section 4.2].  The version of XML used for SOAP message Infosets
SHOULD be chosen to be compatible with the protocol bindings used not just
at the original sender, but also at any intermediaries likely to be
employed.

The [version] property of the document information item MAY be supplied for
any XML message infoset, and MUST be supplied if the version is other than
XML 1.0.  If supplied, the [version] property MUST designate a version of
XML usable to serialize the message Infoset.<

The XML infoset of a SOAP message MUST NOT contain a document type
declaration information item.

...
</proposed>
--------



Unresolved Question
-------------------

Should we specify a standard fault to be generated by a sending binding in
the case where the Infoset is XML Version X and the binding can't handle
that version.  Example scenario:  2nd hop of multihop.  First hop has sent
XML 1.1, 2nd hop binding can't do it.  Should the 2nd hop reflect a
standard or binding-specific fault back to the original requestor?

Noah

[1] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.html

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Wednesday, 21 April 2004 00:08:05 UTC