- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Thu, 12 Sep 2002 11:35:19 -0700
- To: <noah_mendelsohn@us.ibm.com>, "Martin Gudgin" <mgudgin@microsoft.com>
- Cc: <xml-dist-app@w3.org>
>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