3256 2006-05-09 11:15:50 +0000 BC dates 2008-02-08 18:46:54 +0000 1 1 1 Unclassified XML Schema Datatypes: XSD Part 2 1.1 only PC Windows XP RESOLVED FIXED cluster: clarification resolved P2 minor --- 1 mike cmsmcq www-xml-schema-comments oldest_to_newest 9670 0 mike 2006-05-09 11:15:50 +0000 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? 16276 1 davep 2007-08-27 01:59:03 +0000 (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. 17193 2 cmsmcq 2007-10-14 19:13:47 +0000 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. 18764 3 cmsmcq 2008-02-05 03:36:40 +0000 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). 18883 4 cmsmcq 2008-02-08 18:46:54 +0000 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.