24541 2014-02-05 23:10:21 +0000 Missing KindTests in the analysis 2014-05-15 14:00:22 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED FIXED P2 minor --- 1 abel.braaksma mike cmsmcq public-qt-comments oldest_to_newest 99849 0 abel.braaksma 2014-02-05 23:10:21 +0000 A KindTest (such as attribute(), processing-instruction(), text()) is not mentioned in the break-down of expressions. The closest you can get is an Axis Step (19.8.7.7 Streamability of Axis Steps, http://www.w3.org/TR/xslt-30/#streamability-of-axis-steps), but this section does not mention KindTests. While writing this up, it occurs to me that the rules are actually sound here, as in the GSR under adjusted sweep S', a KindTest has a special rule, and it is itself already on an axis, which are mentioned under Axis Steps. I nevertheless add this bugreport, because I think a small Note under 19.8.7.7 on axis steps containing KindTests can be beneficial in understanding this special case and may remove possible confusion. 99887 1 mike 2014-02-06 09:53:51 +0000 A KindTest is not itself an expression (or a "construct"), it's only of interest in that it forms part (sometimes the entirety) of an AxisStep. So any impact of KindTests on streamability should be covered in the rules for AxisSteps. I've no objection to adding a Note, though I'm not quite sure what it needs to say. 100383 2 cmsmcq 2014-02-12 10:28:40 +0000 The WG discussed this during the ftf meeting in Prague and concluded that a note or some expository text in the opening text of 19.8.7 might serve the case, pointing out that as a consequence of the rule of classifying by the most specific production for which an entry appears, expressions like processing-instruction() should be sought not under KindTest (which does not appear) but under AxisStep (which does). And similarly for child::x, which should be analysed not under PathExpr but (again) under AxisStep (which is more specific). 100721 3 mike 2014-02-16 20:30:29 +0000 Further explanations have been added, as suggested. 101987 4 abel.braaksma 2014-03-06 16:01:23 +0000 Not sure I should reopen this issue just because of a tiny typo, but this once I'll take the risk to do so (because it was introduced with this change): under 19.8.7, second bullet point in the first list, the term ForwardsAxis is used, which should be ForwardAxis. Other typos I'll place in a collective issue. 104351 5 mike 2014-04-24 14:38:37 +0000 Noted and fixed. Editorial note: axes are consistently "forward" and "backward", whereas compatibility is consistently "forwards" and "backwards". At least it's consistent.