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 30099 - [xslt30] Incorrect proforma for xsl:number/@start-at
Summary: [xslt30] Incorrect proforma for xsl:number/@start-at
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Proposed Recommendation
Hardware: PC All
: 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: 2017-04-25 16:25 UTC by Michael Kay
Modified: 2017-06-01 20:50 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2017-04-25 16:25:13 UTC
The proforma for xsl:number (section 12 and appendix D) gives

start-at? = { integer }

However, the prose is clear (along with examples and test cases) that the value can be a sequence of integers.

The spec was changed as a result of bug #27060 to allow a sequence of integers, but the proforma was not updated.

If we were at a different stage of the process I would suggest changing the proforma to

start-at? = { integers }

and adding "integers" as a data type in section 2. However, there are complications involving whitespace - the prose description says that start-at must match the regular expression -?[0-9]+(\s+-?[0-9]+)* which does not allow leading and trailing whitespace.

We need to make the minimum change to the spec to make the proforma consistent with the prose specification, and that is achieved by changing the proforma to

start-at? = { string }

The schema describes it simply as an AVT so no change is needed there.

Note on W3C Process: substantive changes are not allowed between PR and REC. "Changes that reasonable implementers would not interpret as changing architectural or interoperability requirements or their implementation" are deemed to be non-substantive. By contrast, changes that "resolve ambiguities" are deemed substantive. Although this bug resolves an inconsistency in the spec, I consider that given the evidence of examples and test cases, every reasonable implementer would interpret the spec as allowing a sequence of integers here, so the inconsistency does not amount to an ambiguity.
Comment 1 Michael Kay 2017-05-04 18:00:46 UTC
The change was agreed by the WG and has been applied.