[Bug 5126] Assertions: usability

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

           Summary: Assertions: usability
           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: mike@saxonica.com
         QAContact: www-xml-schema-comments@w3.org


I've been doing some experiments with assertions.

It seems to be quite common to define an assertion that constrains some element
deep within the document to be consistent with an attribute of the document
element (for example, a version attribute). For example one might constrain an
XSLT stylesheet to say:

<xs:assert test="if (@version='1.0') then empty(.//xsl:result-document) else
true()"/>

The problem about such assertions is that they have to appear on the
complexType of the document element (because they apply to the subtree rooted
at that node). This makes it almost impossible when the assertion fails to
provide diagnostics  saying where in the instance document the problem actually
arises.

I'm not proposing that we change the rule that the assertion belongs with the
type that defines the subtree within which the constraint applies. But I think
there might be a case for allowing the condition to be specified in two parts:

<xs:assert select=".//xsl:result-document"
test="empty(ancestor-or-self::xsl:*[@version='1.0'])"/>

(which in this example is actually a more precise expression of the desired
constraint, since the version attribute can appear anywhere)

The default for select would be select="." which leaves test with the current
meaning. In the presence of the select attribute, the test would be applied to
each node selected by the select expression, allowing the diagnostics to refer
to the position of that selected node. Furthermore, this allows multiple errors
to be reported if more than one selected element is invalid.

I know that some might think this introduces unnecessary complexity. But in its
absence, users are going to have to do some complex queries to find out where
the errors in their documents actually are.

Received on Tuesday, 2 October 2007 17:07:34 UTC