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 29310 - [FO31] Invalid and ambiguous XPath expression in normative part of section 5.4.3 fn:substring
Summary: [FO31] Invalid and ambiguous XPath expression in normative part of section 5....
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
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: 2015-11-28 08:17 UTC by Abel Braaksma
Modified: 2016-03-22 09:56 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2015-11-28 08:17:13 UTC
Under 5.4.3 fn:substring we write:

<quote>
More specifically, the three argument version of the function returns the characters in $sourceString whose position $p satisfies:

fn:round($start) <= $p < fn:round($start) + fn:round($length)
</quote>

But this is an illegal XPath expression. If it isn't meant to be an XPath expression, I thing the text should say so, but even then, the associativity is ambiguous. One might read this as:

(fn:round($start) <= $p) < (fn:round($start) + fn:round($length))

or as:

fn:round($start) <= ($p < fn:round($start)) + fn:round($length)

But neither expressions make much sense in light of the text. Perhaps the following was meant (in which case parentheses are no longer necessary)?

fn:round($start) <= $p and $p < fn:round($start) + fn:round($length)

Alternatively, we might consider using the same approach as for fn:subsequence, which has a clearer way of defining in a proper XPath what the function is supposed to return.

-------

Note that there are other places where ambiguous associativity is used, for instance '1<=N<=S" in fn:replace and "-π/2 <= θ <= +π/2" in math:asin, but in these case the textual context makes it clear that these are not meant to be read as XPath expressions, moreover, the mathematical meaning of "between" is easily deducted from the text.
Comment 1 Michael Kay 2015-11-28 10:10:38 UTC
These expressions (A < B < C) were of course intended to be read as mathematical formulae rather than XPath expressions, but I take your point.
Comment 2 Michael Kay 2015-12-08 16:17:21 UTC
Agreed that we will fix this by changing A < B <= C to (A lt B and B le C), i.e. to a valid XPath expression. Note that fn:subsequence is already written this way.
Comment 3 Michael Kay 2015-12-16 12:26:08 UTC
The change has been applied.