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 29547 - Castable tests assume no year zero
Summary: Castable tests assume no year zero
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: O'Neil Delpratt
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-30 18:16 UTC by Michael Kay
Modified: 2016-10-24 21:09 UTC (History)
2 users (show)

See Also:


Attachments

Description Michael Kay 2016-03-30 18:16:44 UTC
In prod-CastableExpr, tests

cbcl-castable-gYear-002 
cbcl-castable-gYear-003 
cbcl-castable-gYearMonth-003 
cbcl-castable-gYearMonth-004

assume year zero is not allowed. This is true of XSD 1.0 but not of XSD 1.1 But the tests have no dependency on XSD version.
Comment 1 O'Neil Delpratt 2016-04-19 10:03:48 UTC
I am suggesting that we split these tests into two: One for XSD 1.0 and the other for XSD 1.1. I will make the change.
Comment 2 O'Neil Delpratt 2016-04-19 10:14:05 UTC
See also the bug #29576 which suggests a minimum and maximum year that all implementations must support.
Comment 3 O'Neil Delpratt 2016-05-10 15:13:51 UTC
Bug fixed according to the resolution: make these tests (a) dependent on support for XSD 1.1, and (b) allow an FODT0001 result for implementations whose minimum year is 0001.
Comment 4 Benito van der Zander 2016-05-17 21:06:12 UTC
That would affect these tests, too: ?

cbcl-cast-gYear-002: "0000" cast as xs:gYear
cbcl-cast-gYearMonth-003:  "0000-05" cast as xs:gYearMonth
Comment 5 Benito van der Zander 2016-05-17 21:12:10 UTC
And

cbcl-cast-gYear-003: "-0000" cast as xs:gYear
cbcl-cast-gYearMonth-004: "-0000-05" cast as xs:gYearMonth


?
Comment 6 O'Neil Delpratt 2016-09-20 09:41:32 UTC
(In reply to Benito van der Zander from comment #5)
> And
> 
> cbcl-cast-gYear-003: "-0000" cast as xs:gYear
> cbcl-cast-gYearMonth-004: "-0000-05" cast as xs:gYearMonth
> 
> 
> ?

I have committed a fix for these test cases.
Comment 7 Michael Kay 2016-10-05 12:04:01 UTC
I don't understand the change that was made to these tests:

> cbcl-cast-gYear-003: "-0000" cast as xs:gYear
> cbcl-cast-gYearMonth-004: "-0000-05" cast as xs:gYearMonth

Previously the tests had no XSD dependency, and were expected to fail FORG0001, which I think was correct: year zero is not valid under XSD 1.0.

Now the tests have been changed to have a dependency on XSD 1.1. I think this makes the cast succeed. But the expected results have been changed to allow a choice of errors: FORG0001 or FODT0001.

I think there should be two versions of each of these two tests:

(a) an XSD 1.0 version which expects FORG0001

(b) an XSD 1.1 version which expects either success, or FODT0001.
Comment 8 Andrew Coleman 2016-10-21 07:22:01 UTC
The WG agreed the following resolution:

ACTION A-657-19: O'Neil to look at tests cbcl-cast-gYear-003 and cbcl-cast-gYearMonth-004 and to fix as proposed by MKay in comment #7 of bug 29547 (drop errors as allowed result)
Comment 9 O'Neil Delpratt 2016-10-24 16:08:14 UTC
Bug fixed accordingly to comment 7 and 8
Comment 10 Benito van der Zander 2016-10-24 21:09:14 UTC
Now there are still cbcl-cast-gYear-002, cbcl-cast-gYearMonth-003 and cbcl-cast-gYearMonth-004 running with xsd 1.1 and only accepting FORG0001/FODT0001