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 24384 - [FO30] Typos and link issues under fn:unparsed-text-lines(), and relation with fn:unparsed-text-available()
Summary: [FO30] Typos and link issues under fn:unparsed-text-lines(), and relation wit...
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Proposed Recommendation
Hardware: PC Windows NT
: P2 minor
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: 2014-01-24 16:16 UTC by Abel Braaksma
Modified: 2014-02-19 09:07 UTC (History)
1 user (show)

See Also:


Attachments

Description Abel Braaksma 2014-01-24 16:16:30 UTC
In the third paragraph of fn:unparsed-text-lines() [1], the text "The result is a thus a sequence of strings", should probably read "The result is thus a sequence of strings".

The links under the expressions in the second paragraph extend to the whole expressions, as opposed to only the individual functions (tokenize, unparsed-text etc). Perhaps this is a limitation of the build script, however, if it is, I think it is more readable without the links.

Furthermore, since the function is now deterministic (as opposed to non-deterministic from the streaming discussion a while ago), I think it is good to allow fn:unparsed-text-available() to also apply to fn:unparsed-text-lines(). Currently, there's no such relation between those functions.

[1] http://www.w3.org/TR/xpath-functions-30/#func-unparsed-text-lines
Comment 1 Abel Braaksma 2014-01-24 16:25:24 UTC
Oh, and I just noticed: the second example in the same section has a double "))", it should be one closing parenthesis at that position.
Comment 2 Michael Kay 2014-02-19 09:06:25 UTC
Discussed by the WG, closed with the following action:

1. "is a thus a". Fixed in both 3.0 and 3.1.

2. The generation of links to functions is automated and I agree it's very clumsy. However, it's been unchanged for a long time (since pre-2.0) and there's no immediate urgency, so not fixing this right now.

3. We believe that unparsed-text-available() does indeed apply to unparsed-text-lines(). The linkage is there, but is indirect: the specification of unparsed-text-lines makes clear that it fails under exactly the same circumstances as unparsed-text, and these are exactly the circumstances under which unparsed-text-available returns false. I have added a statement to this effect as a Note in both 3.0 and 3.1:

"Since the function <function>unparsed-text-lines</function> succeeds or fails under exactly the same circumstances as <function>unparsed-text</function>, the <function>unparsed-text-availabl</function> function may equally be used to test whether a call on <function>unparsed-text-lines</function> would succeed."

4. The mismatched parentheses in the code example have been fixed (in 3.0 and 3.1).