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 6346 - [FO] fn:number() example
Summary: [FO] fn:number() example
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: 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: 2009-01-03 16:37 UTC by Michael Kay
Modified: 2009-01-28 20:58 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2009-01-03 16:37:08 UTC
The second example for fn:number() (section 14.4.1) is:

fn:number($item2) returns NaN.

Now $item2 (scroll up to the start of section 14) is bound to an element of the form

  <line-item>
    <description> ... </description>
    <price> ... </price>
    <quantity>5.0</quantity>
      ...
  </line-item>

Since we are told that quantity is typed as xs:decimal, we must infer that this element is schema-validated, and it therefore seems highly likely that the line-item element would be defined with element-only content. In this situation I believe number() should fail with a type error; because although number() itself is resilient to casting errors, the atomization of the argument is done under the function calling rules and will fail in the case of element-only content.

I think it would be better to use a different example, say number($item1/description) (having given this element some non-numeric content).
Comment 1 Michael Kay 2009-01-03 16:47:20 UTC
Note also, fn:number() says twice that "If $arg is the empty sequence, NaN is returned.".
Comment 2 Michael Kay 2009-01-28 20:57:52 UTC
Erratum E36 has been raised to fix the first problem. The second (duplication) does now harm and will be left alone. The bug is being marked fixed and closed.