W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2008

[Bug 5726] XPath Context for Assertions must not include Element Name

From: <bugzilla@farnsworth.w3.org>
Date: Fri, 30 May 2008 20:08:49 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1K2Au9-0003js-5g@farnsworth.w3.org>


           Summary: XPath Context for Assertions must not include Element
           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.

Received on Friday, 30 May 2008 20:09:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:08 UTC