29796 2016-08-26 19:34:28 +0000 [XSLT30] Keys and documents 2016-09-09 21:50:23 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC Windows NT RESOLVED FIXED P2 editorial --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 127244 0 abel.braaksma 2016-08-26 19:34:28 +0000 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. 127245 1 mike 2016-08-26 20:58:54 +0000 I don't see a good justification to add this feature / lift this restriction at this stage of development of a spec that has already been almost ten years in the making. 127246 2 abel.braaksma 2016-08-27 16:59:19 +0000 You're probably right. I figured it was an omission/oversight, but if that's not the case (or if the oversight is something we can live with), I agree we shouldn't change it. That said: the sentence under xsl:key could benefit from mentioning that it only applies to document nodes, it would remove the discrepancy. 127247 3 mike 2016-08-27 17:17:11 +0000 Historically, when XPath 2.0 introduced the possibility of parentless element nodes (and text nodes etc) into the data model, we were concerned about the potential complexity and implementation overhead of allowing keys to apply to such nodes, and we made a conscious decision to exclude this possibility. Whether that decision is still justified is an open question, but I don't think that now is a good time to start reviewing and reconsidering it. 127340 4 abel.braaksma 2016-09-08 17:03:50 +0000 As discussed at today's meeting, the WG decided that we leave the functionality as-is, however, the editor was requested to write a small clarification, as per the suggestion in comment #2. Reclassifying this as editorial. 127360 5 mike 2016-09-09 21:50:23 +0000 The requested note has been added.