This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30396 - [XSLT30] patterns like "descendant::para" don't match parentless nodes like "child::para" does, there's no descendant-or-top rule
Summary: [XSLT30] patterns like "descendant::para" don't match parentless nodes like "...
Status: RESOLVED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 major
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-22 13:00 UTC by Abel Braaksma
Modified: 2019-02-20 10:31 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2019-01-22 13:00:56 UTC 
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.
Comment 1 Michael Kay 2019-01-22 16:40:12 UTC 
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.
Comment 2 Abel Braaksma 2019-02-02 14:49:18 UTC 
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.