W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2016

[Bug 29796] New: [XSLT30] Keys and documents

From: <bugzilla@jessica.w3.org>
Date: Fri, 26 Aug 2016 19:34:28 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29796-523@http.www.w3.org/Bugs/Public/>

            Bug ID: 29796
           Summary: [XSLT30] Keys and documents
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

I have to admit that I do not use keys that much, and today it came as a
surprise that I couldn't use it with non-rooted nodes (that is, nodes that are
not rooted at a document node).

Under xsl:key this is not explicit, in fact, we even say "an xsl:key element
applies to all nodes that match the pattern specified in the match attribute".

However, under fn:key we are explicit and even have an error if you
inadvertently use the fn:key function with the 3rd argument (or the context
node) on a node that has no document at its root (XTDE1270).

If the fn:key function is used in a pattern, this error would never be raised,
but you would also never have a positive match.

I don't understand why we have this limitation, is it historical? I would like
to drop it, it doesn't seem to make much sense and with the advent of allowing
any kind of node or nodes as input to a stylesheet transformation, it is a
limitation and complexity we can live without.

Note that we *do* require it to be applicable to temporary trees, so if the
argument would be that it only applies to input trees from fn:doc etc, and that
it is too much of a performance hit to remove this limitation, I don't think
that it matters much in practice.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 26 August 2016 19:34:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:01 UTC