- 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