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:36:01 UTC