http://www.w3.org/Bugs/Public/show_bug.cgi?id=5726
Summary: XPath Context for Assertions must not include Element
Name
Product: XML Schema
Version: 1.1 only
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Structures: XSD Part 1
AssignedTo: cmsmcq@w3.org
ReportedBy: noah_mendelsohn@us.ibm.com
QAContact: www-xml-schema-comments@w3.org
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