30396 2019-01-22 13:00:56 +0000 [XSLT30] patterns like "descendant::para" don't match parentless nodes like "child::para" does, there's no descendant-or-top rule 2019-02-20 10:31:00 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Recommendation PC Windows NT RESOLVED INVALID P2 major --- 1 abel.online mike public-qt-comments oldest_to_newest 129486 0 abel.online 2019-01-22 13:00:56 +0000 In XSLT 3.0 we allowed "descendant::", but the rewrite rules like we have for "child::" was not updated. We also allowed the "namespace::", "descendant-or-self::" and "self::" axis, but for the namespace axis a rule was added. For self (and by extension, descendant-or-self) there's no conflict with selecting the top node of a parentless tree. As written, "descendant::para" would not match a parentless para element, but "child:para" would. I don't think that it the intention of the spec here. I propose therefore an erratum entry where we introduce the same concept as child-or-top, but for the descendant axis: descendant-or-top. Alternatively, we could simply say: "where "descendant::x" is used, replace it with "descendant-or-self::x", which would have the same effect. 129487 1 mike 2019-01-22 16:40:12 +0000 The peculiar rule for child-or-top and attribute-or-top was introduced in 2.0 to ensure that 1.0 patterns like "title" and "@version" had the intuitive effect in the presence of parentless elements and attributes. The idea was that people would expect these to match ANY element or attribute with the relevant name. I don't think there's a similar intuitive expectation that descendant::title should match title elements that aren't the descendant of anything. Quite the contrary. But it doesn't really matter what I think. The spec is clear about what descendant::title means, and whether we like the semantics or not, there is no justification for attempting to make a change now. 129489 2 abel.online 2019-02-02 14:49:18 +0000 Interesting, I really thought this was an omission considering how the rest of the text was written. In non-pattern expressions, child::x fully overlaps with descendant::x. In patterns this is no longer true and these sets are disjunct, child::x includes the top node, descendant::x does not. Saying that child::x selects top and saying descendant::x does not does not sound intuitive to me all, to be honest (but I have always stumbled on the "automatic top selection"). But I see your argument, it didn't occur to me that this was specifically intended this way, which is good (though I find it odd, that is not a good enough argument to break open the REC). I had no intention to propose a change, just thought it was an omission. I propose this bug as invalid.