[Bug 5297] Drop restriction of assertions to down-pointing XPaths?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5297

           Summary: Drop restriction of assertions to down-pointing XPaths?
           Product: XML Schema
           Version: 1.1 only
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: cmsmcq@w3.org
        ReportedBy: cmsmcq@w3.org
         QAContact: www-xml-schema-comments@w3.org


In our design of assertions and conditional type assignment, we have
for some time taken the position that the XPath expressions used
should not point up or left (or right) from the element on which the
assertions are checked (or the type of which is being calculated).
This was not a unanimous decision, if I recall correctly, but one to
which some WG members assented reluctantly.  

It seemed clear, when we reached agreement on this point, that the
prohibition was inconvenient, but as far as we could tell it did not
actually affect the expressive power of assertions.

One example used at the time (see
http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2006Mar/0041.html
for an appearance of this example in WG discussion) was that of the
HTML 'input' and 'form' elements: 'form' is legal only within an
'input' element.  A natural way to express the constraint is to 
write an assertion of the form 

  ancestor::html:form

or

  count(ancestor::html:form) > 0

in the declaration of the type assigned to the input element.  We came
to the conclusion that upward-pointing assertions were not essential
to this scenario, however, when we realized that one could place the
assertion on the HTML element, and formulate it as 

  count(.//input) = count(.//form//input)

Recently I have become aware of a fallacy in our reasoning, which
leads me to conclude that we reasoned our way to a false conclusion
and that we need to reconsider the decisions based in part on that
conclusion.

HTML is defined as a modular vocabulary, and the forms module is
intended to be usable in arbitrary XML vocabularies, not only in
(X)HTML itself.  Placing the assertion on the HTML element does not
guarantee that it will be enforced wherever 'form' and 'input' are
used.  There is no element on which the assertion can be placed so
that it reliably enforces the constraint.  It appears, then, that we
were wrong to believe that the current form of assertions in XSDL 1.1
could be used to handle the HTML form/input use case.

Under the circumstances, I no longer believe it plausible to forbid
assertions to point upward in the tree, and believe that we should
drop the restriction (and with it, our mechanisms for 'tree trimming'
prior to XPath evaluation).

Received on Friday, 30 November 2007 04:26:26 UTC