W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2002

RE: Issue 356: Allow unqualified elements as children of Body

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 12 Sep 2002 15:03:04 -0400
To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Cc: "Martin Gudgin" <mgudgin@microsoft.com>, xml-dist-app@w3.org
Message-ID: <OFD7D4D982.BD5AF9CF-ON85256C32.00676875@lotus.com>

Henrik:

Most of this is fine, with one significant exception noted below,  though 
I would probably go with SHOULD be namespace qualified, which seems more 
in the spirit of the recommendation note below.

The exception is:  I don't think this is the right issue under which to 
back into allowing PIs in the body.   Thus, I would want to be careful 
with:

"The Body EII can contain any II that is not explicitly prohibited by this 
specification."

To make sure we've really ruled everything that we intend to.  Also, I'm 
not sure what the normative significance of:

"All such IIs and their values are considered significant."

is.  Leave that sentence out?

Otherwise good, I 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>
09/12/2002 02:35 PM

 
        To:     <noah_mendelsohn@us.ibm.com>, "Martin Gudgin" <mgudgin@microsoft.com>
        cc:     <xml-dist-app@w3.org>
        Subject:        RE: Issue 356: Allow unqualified elements as children of Body



>Absolutely.  No question that's what we're trying to say.  The 
>question is 
>whether the existing presentation of those elements is 
>unambiguous on this 
>point.  We're quite careful in most cases to say exactly what 
>is and isn't 
>allowed, and here we don't really say, I think.  Not sure it's 
>a problem, 
>but was curious whether anyone else read it as I did.  Thanks.

This is a good question and at least some clarification may be in order.
There seems to be three subparts to consider:

A) Do we require qualification of immediate children of the Body EII as
currently stated in [2]?

B) Do we require qualification of grandchildren and below of the Body
EII as currently *not* stated in [3]?

C) Depending on the answer to A and B, is the text in part 1, section
2.5 [1] correct?

I think the objection raised in the issue [0] targets both A) and B).

From a strict conformance requirements POW, I don't think we can claim
that anything breaks if the descendants of the Body EII are not
qualified. At the same time I think we want to say that qualification is
a Good Thing (tm) because of the distributed nature of SOAP messages. It
is my impression that this was at least a part of the reason for the
current formulation in [2]. However, one can argue the use of enforcing
such policies by using strict MAY/SHOULD/MUST requirement style language
is questionable.

Another point is that even if we do not require namespace qualification,
why do we call out EIIs as compared to other child IIs of the Body EII?
Given that [1] already states that 

                 Part 1 of this specification (this document) mandates
                 no particular structure or interpretation of these
                 elements, and provides no standard means for
                 specifying the processing to be done.

it seems reasonable this applies not only to EII but to other II like
whitespace and the like. This also seems to be in better conformance
with the XML Infoset spec, section 3 [4], which states that we must say
what to do with other IIs.

Proposal
--------

I think we can clarify the current text by making the changes below.
From a semantic POW, I think these changes are in line with what we have
now and so I don't see them as more than clarifications.

1) We do NOT require namespace qualification of immediate children of
the Body EII but add a note that this is recommended. That is, we change

                 Zero or more namespace qualified element
                 information items in its [children] property.

to

                 Zero or more element information items in its
                 [children] property. Such element information
                 items MAY be namespace qualified.

                 Note: Even though it is not a requirement of
                 this specification, it is strongly recommended
                 that children element information item be
                 namespace qualified.

2) We change the current text in [3] to cover IIs in general and their
possible values:

                 The Body EII can contain any II that is
                 not explicitly prohibited by this specification.
                 All such IIs and their values are considered
                 significant. The values of any of the properties
                 of those IIs are not constrained by this
                 specification.

                 SOAP defines one particular direct child of the
                 SOAP body, the SOAP fault, which is used for
                 reporting errors (see 5.4 SOAP Fault).

Note that the last paragraph hasn't changed--it is just included for
completeness.

3) In part 1, section 2.5 [1], we change

                 An ultimate SOAP receiver MUST correctly process the
                 immediate children of the SOAP body (see 5.3 SOAP Body).

to

                 An ultimate SOAP receiver MUST correctly process the
                 contents of the SOAP body (see 5.3 SOAP Body). 

Comments?

Henrik

[0] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x356
[1]
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml#structinterpbod
ies
[2] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml#soapbody
[3] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml#soapbodyel
[4] http://www.w3.org/TR/2001/REC-xml-infoset-20011024/#conformance
Received on Thursday, 12 September 2002 14:56:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:11 GMT