Re: Proposal for resolution of issue 176

Overall, I like it.  A couple of small questions/suggestions:

* The changes to 4 and 4.2 seem a bit strong wrt/ comments and maybe 
whitespace.  Would it be reasonable to say that comments and/or whitespace 
are insignificant if included.  Senders MAY include them if useful as 
documentation, but not for other processing.  Receivers must accept. 
Intermediaries MAY but NEED NOT relay?

* The changes in 4 and 4.2 need to be worded carefully to make sure 
they're not taken to preclude character info, comments (and I suppose 
PI's) within header and body blocks. 

What do you think?   Thanks.

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







"Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Sent by: xml-dist-app-request@w3.org
02/11/2002 12:37 AM

 
        To:     <xml-dist-app@w3.org>
        cc: 
        Subject:        Proposal for resolution of issue 176



I took an action item to propose a resolution for issue 176 [1]
regarding what kind of information intermediaries must relay when it
comes to comments and similar xml information items. However, working on
this a bit more, it seems that at least portions of the issue applies
equally to any SOAP sender and SOAP receiver and not just
intermediaries. Note that this does mail does not address issue 137 [2]
which is being dealt with in parallel.

Discussion
----------

While the SOAP 1.2 spec, part 1 is clear on what elements can be present
in a SOAP envelope and where, in particular with respect to immediate
child elements of the envelope and the header and body, it is less clear
about what to do with comments etc. As mentioned, this is not only a
problem for intermediaries but for any SOAP node receiving a SOAP
message. The intent of the proposal below is to clarify the rules for
such information.

Proposal Outline
----------------

The proposal is to *disallow* any child information items other than the
ones that are explicitly allowed for both the document information item,
the Envelope element information item and the Header element information
item. This proposal says nothing about SOAP Header blocks and Body
element information items which are being discussed as part of issue 137
[2].

In addition, this mail attempts to deal with the related question
brought up by 176 as to what values to use for SOAP defined attributes
like mustUnderstand and how they must be relayed.

Specific Text Modifications
---------------------------

* In section 4 at the very beginning, add to first sentence:

A SOAP message has an XML Infoset that consists of a document
information item with exactly one child, which is an element information
item as described below. A SOAP sender MUST NOT include any other child
information items including processing instruction information items,
comment information item, or a document type declaration information
item. With the exception of a document type declaration information item
(see the "DTDNotSupported" SOAP fault code in section 4.4), a SOAP
receiver MUST ignore such information items and a SOAP intermediary MAY
discard them if relaying a SOAP message.

* Add the following paragraph to each of the descriptions of the SOAP
envelope (section 4) and SOAP header (section 4.2) element information
items:

A SOAP sender MUST NOT include any other child information items
including element, processing instruction, unexpanded entity reference,
character, and comment information items. A SOAP receiver MUST ignore
such information items and a SOAP intermediary MAY discard them if
relaying a SOAP message.

* In section 4.2.2, add the sentence at the end

If relaying the message, a SOAP intermediary MAY omit the SOAP actor
attribute information item for SOAP header blocks targeted at the
ultimate SOAP receiver.

* In section 4.2.3, add the two paragraphs at the end:

When a mustUnderstand SOAP header block attribute information item is
present, a SOAP sender SHOULD use the canonical representation of the
attribute value (see schema ...). A SOAP receiver MUST accept any valid
lexical representation of the attribute value. If an invalid value is
encountered, a SOAP receiver MUST generate a "Sender" fault.

If relaying the message, a SOAP intermediary MAY substitute a
non-canonical value with the canonical value and MAY omit the SOAP
mustUnderstand attribute information item if the value is "false" or
"0".

Comments?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x176
[2] http://www.w3.org/2000/xp/Group/xmlp-issues#x137

Received on Monday, 11 February 2002 15:06:18 UTC