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 30013 - [XSLT30] (editorial) Unclear or inverse Note in definition of non-positional predicates
Summary: [XSLT30] (editorial) Unclear or inverse Note in definition of non-positional ...
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 editorial
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: 2016-11-19 00:46 UTC by Abel Braaksma
Modified: 2016-11-20 19:15 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2016-11-19 00:46:41 UTC
We say under non-positional predicates (section 19.8.10 Classifying Patterns):

"The exception for nested predicates is to avoid disqualifying patterns such as match="p[@code = $status[last()]]"."

But the pattern "p[@code = $status[last()]]" is not a disqualifying pattern, it is allowed and considered a non-positional pattern, and I think we explicitly allow it.

Perhaps we meant to say:

"The exception for nested predicates is to allow patterns such as match="p[@code = $status[last()]]", which are motionless [since they do not need to retain positional information of the streamed node]."

(the added "[since....]" is just a suggestion)
Comment 1 Michael Kay 2016-11-19 13:48:29 UTC
"to avoid disqualifying" was intended to be read as "to ensure that we do not disqualify". I'll find a way of rewording it to avoid the misreading.
Comment 2 Michael Kay 2016-11-19 14:28:46 UTC
Rewritten as

The exception for nested predicates is there to ensure that patterns such as <code>match="p[@code = $status[last()]]</code> are not disqualified.

Not change-marked.

Hope that's OK.
Comment 3 Abel Braaksma 2016-11-20 19:15:06 UTC
Looks good to me, tx.