This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
On today's Schema telcon it was mentioned that the XPath context for evalution of complex type assertions is trimmed such that the context node is the element node being validated. I believe that carrying in the name of the element into the XPath context is significant bug, that should if possible be addressed before XSD 1.1 goes to Last Call for Candidate Recommendation. Reason: it's a very important architectural invariant of XSD that complex types have the same extension (validate the same content) independent of the name of the element to which they are applied, or (except where we messed up on key/keyref of locally scoped elements) independent of siblings or ancestors. I think it's fair to say that XQuery depends on this characteristic in typing things like function results with Schema types. In any case, carrying the element name violates this invariant, as one could write an XPath that would be true iff the element had some particular name. Possible resolutions: I assume that several possible "fixes" could be considered. My favorite for the moment is: * Set the element local name and namespace name to some fixed pair, as was proposed as an option for assertions on simple types. I think a local name of "_" was suggested, with some W3C-controlled namespace. Alternatives I might live with, but that seem less desirable, include: * Making it a runtime error for the XPath to reference those properties on the context node. * Indicating that XPaths MUST NOT reference that information, implying that schemas are nonconforming if they do (though this would beg the question of whether it's a dynamic or static error, etc.) * Indicating that XPaths SHOULD NOT reference the element name, and providing a note warning that 1) results of such references may be implementation defined and/or 2) warning that specifications using XSD complexTypes (e.g. as the return type of a function) MAY prohibit such references. Anyway, I'm agreeable to simple solutions, but I think this is a serious architectural flaw that should be addressed if possible. Several of the possible fixes look pretty easy to me editorially, and low risk architecturally, but perhaps that's just a reflection of my not having been active as an editor for awhile. Noah
I wonder whether this is being excessively purist? I can see users wanting to reuse the same type for two different elements and then attach some constraints, for example (in the schema for schemas) one could imagine defining key, keyref, and unique as having the same complex type, and then add the constraint that the ref attribute is allowed only if the element name is keyref. Do we really want to defend a decision that we aren't allowing users to do this because we thought it was architecturally impure? And users are going to be very confused if they do test the element name and it doesn't match what the element name "really is". Also, we're providing other bits of context like the base URI and the namespace context, which are equally impure.
The XML Schema Working Group discussed this issue at its teleconference of 13 June 2008. There was some support for the idea proposed, there was some support for closing the bug report with a disposition of WONTFIX, and some for closing the report as INVALID (on the grounds that it provides no new information to motivate reopening the design discussion: the salient properties of the current design have been clear from the beginning). Some WG members expressed skepticism that the desired change(s) could be made in the future, and thought a disposition of LATER was illusory, but there was no consensus on this point. The preponderance of sentiment was for LATER, and the question was put to the WG in those terms; there were no dissents. Noah, as the originator(s) of this proposal, the WG would be grateful to you if you would consider this disposition of the issue and let us know by closing the issue that you are willing to accept the WG's decision, or by reopening it that you are dissatisfied and wish the WG to reconsider, or wish to appeal the WG's decision to the Director.