- From: <bugzilla@jessica.w3.org>
- Date: Fri, 26 Aug 2016 19:34:28 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29796
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