[Bug 10299] New: [XSLT 2.0] xsl:number level="any" from="no-match"

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

           Summary: [XSLT 2.0] xsl:number level="any" from="no-match"
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 2.0
        AssignedTo: mike@saxonica.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


When xsl:number is used with level="any" and a from pattern, and no node
matches the from pattern, the spec is reasonably clear that the root node of
the tree should be treated as if it matched the from pattern, and that
numbering should therefore be from the root:

"Let matches-from($node) be a function that returns true if and only if the
given node $node matches the pattern given in the from attribute, or if $node
is the root node of a tree."

However, quite a few tests in the test suite break if you implement this rule
as written. An example is numbering18. These tests are written on the
assumption that if no node matches the from pattern, then no number is
allocated.

Martin Honnen reports on xsl-list that Saxon and Intel are following the
behaviour shown in tests such as numbering18, not the behaviour described in
the spec. We therefore need to decide whether to endorse the spec as written,
or whether to change it to match the behaviour of the tests.

Changing the spec might not be trivial to do, and could end up being messy, 
because the definition in question affects all values of "level". My preference
would be to change the tests, and regard these products as being in error.

The XSLT 1.0 spec is hopelessly ambiguous in this area. However, it is very
likely that these tests were carried forward from 1.0 tests and reflect the
behaviour of at least some XSLT 1.0 implementations.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 5 August 2010 12:08:18 UTC