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 3256 - BC dates
Summary: BC dates
Status: RESOLVED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: PC Windows XP
: P2 minor
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard: cluster: clarification
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2006-05-09 11:15 UTC by Michael Kay
Modified: 2008-02-08 18:46 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2006-05-09 11:15:50 UTC
QT approved comment

In the first note in 3.3.8.1, it's a bit unfortunate to say "The year 1 BCE was represented by a ·year· value of −1" because it begs the question as to what "1 BCE" means. The whole point is that usages differ. In fact "1 BCE" usually refers to a year in the proleptic Julian calendar, not a year in the proleptic Gregorian calendar, and they aren't the same thing. It would be better to say "The year before year 1 in the proleptic Gregorian calendar was represented as -1". Perhaps it would also be appropriate to say that whereas historians have traditionally referred to the year before 1 AD as 1BC [yes, I mean that, "BCE" is a modern and ugly Americanism], we are following ISO-8601:2000 which has decided differently. The "caution should be used" is a wonderful euphemism. Why not just admit "this is an incompatible change. Those previously-valid documents burnt onto imperishable laser discs in your national archives are now invalid. Sorry, you'll just have to live with it.". Alternatively, why not do the decent thing and provide a version attribute to preserve compatibility?
Comment 1 Dave Peterson 2007-08-27 01:59:03 UTC
(In reply to comment #0)

>  Perhaps it would also be appropriate to say that whereas
> historians have traditionally referred to the year before 1 AD as 1BC [yes, I
> mean that, "BCE" is a modern and ugly Americanism], we are following
> ISO-8601:2000 which has decided differently. The "caution should be used" is a
> wonderful euphemism. Why not just admit "this is an incompatible change. Those
> previously-valid documents burnt onto imperishable laser discs in your national
> archives are now invalid. Sorry, you'll just have to live with it.".
> Alternatively, why not do the decent thing and provide a version attribute to
> preserve compatibility?

WRT the point that the change is not backward compatible, please note that 1.0 2E carried a specific warning that this change was expected and users should plan for that change.

I personally believe that it might help clarify the statement "With that possible exception, schemas and data valid under the old interpretation remain valid under the new", if we were to add "(Of course, the actual year represented by valid negative year values will change.)"  Comments would be appreciated.

Comment 2 C. M. Sperberg-McQueen 2007-10-14 19:13:47 UTC
The WG discussed this issue with the XML Query and XSL WGs at the
meetings in Redmond in October 2007.  

The upshot, finally was:  the 1.1 text needs a more candid note about the
compatibility issues entailed by the change in the interpretation of 
negative years.  (We did not agree to change the interpretation back
to the 1.0 form.)

Editors so instructed.
Comment 3 C. M. Sperberg-McQueen 2008-02-05 03:36:40 UTC
A wording proposal for this issue (among others) was placed on the
server on 4 February 2008 at 
http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.omnibus.200801.html (member-only link).
Comment 4 C. M. Sperberg-McQueen 2008-02-08 18:46:54 UTC
The wording proposal mentioned in an earlier comment was considered
and adopted today by the XML Schema Working Group.  Accordingly, I'm
marking this issue resolved.

Since the originator of the issue is a member of the WG, the adoption 
of the proposal by the WG is probably sufficient evidence that the
originator is content with the WG's resolution of the issue.  But if
the editors don't get around to it, it would be convenient if the 
originator could take the time to shift the status of the issue
from RESOLVED to CLOSED.  Thanks.