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 9927 - [XSLT 2.0] xsl:number grouping-size
Summary: [XSLT 2.0] xsl:number grouping-size
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 2.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: http://www.w3.org/TR/xslt20/#number
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-15 10:36 UTC by Tim Mills
Modified: 2010-08-08 21:38 UTC (History)
0 users

See Also:


Attachments

Description Tim Mills 2010-06-15 10:36:55 UTC
The specification says very little about permitted values for the grouping-size attribute of xsl:number (other than it must be a 'number').

<xsl:number
  ...
  grouping-size? = { number } />

Can this be clarified?  e.g. must be castable to xs:positiveInteger 

I'd expect XTSE0020 and XTDE0030 to cover the static and dynamic error cases.

The test suite doesn't appear to contain tests which might cause such errors, and I've observed an XSLT implementation which rejects non-integer numeric values.
Comment 1 Michael Kay 2010-06-15 11:03:41 UTC
Good point. I would think that it makes sense to require it to be a string in the lexical space of xs:positiveInteger.

XSLT 2.0 uses exactly the same wording as 1.0, which simply requires a "number". One could argue that "number" in XSLT 1.0 means xs:double, but since there are no clues what to do with non-integer values, it's hard to argue that they should be supported on compatibility grounds.

Michael Kay (personal response)
Comment 2 Michael Kay 2010-07-01 16:54:54 UTC
Proposal accepted today: the value is a string in the lexical space of xs:decimal; it's then rounded using round(); if the result is positive it is used as the grouping size; if it's zero or negative then it's ignored.
Comment 3 Michael Kay 2010-07-15 09:53:11 UTC
Resolved as in comment #2; this will be erratum E51.