W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2017

[Bug 30099] New: [xslt30] Incorrect proforma for xsl:number/@start-at

From: <bugzilla@jessica.w3.org>
Date: Tue, 25 Apr 2017 16:25:13 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-30099-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=30099

            Bug ID: 30099
           Summary: [xslt30] Incorrect proforma for xsl:number/@start-at
           Product: XPath / XQuery / XSLT
           Version: Proposed Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 25 April 2017 16:25:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 16:25:21 UTC