RE: Dates and Times in XML Schema Part 2

Mike:
Thank you for your comments.  Some reactions inline below.
In general, we took ISO 8601 as a starting point for designing the date/time datatypes but deviated from it in several details.

All the best, Ashok 
===========================================================


-----Original Message-----
From: Kay, Michael [mailto:Michael.Kay@softwareag.com] 
Sent: Thursday, February 07, 2002 8:01 AM
To: www-xml-schema-comments@w3.org
Cc: w3c-query-operators@w3.org
Subject: Dates and Times in XML Schema Part 2

Some comments regarding dates and times in XML Schema Part 2 [Schema-2]
=======================================================================

These questions are prompted by a reading of XML Schema Part 2 in
conjunction with ISO 8601:2000. (XML Schema references ISO 8601:1988, but I
do not have a copy of this to hand; I believe the differences are minor.)

1. Schema-2 states in D.3.2 that the year "0000" is not legal. ISO 8601
defines a "prolaptic Gregorian calendar" [I think "proleptic" is probably
intended, but that's not relevant] containing the consecutive years -0002,
-0001, -0000, +0001 +0002. Does D.3.2 therefore imply that a date
represented in Schema-2 as -0002-05-05 is the same as the date represented
in ISO 8601 as -0001-05-05? If this were so, I would expect this deviation
to be stated rather more explicitly.
[AM] In the 1998 version on ISO 8601 the year 0 was not allowed.  In fact,
year values ranged from 0001 to 9999 (Section 5.2). XML Schema extended this to allow more than 4 digits in years and negative years but year 0000 was disallowed to mirror the fact that 1AD immediately follows 1BC.  The 2000 version on ISO 8601, as you point out, allows the year 0.  Some of us think this is an error.  The XML Schema WG has an open action item to resolve this issue.

2. ISO 8601 allows either comma or period as the decimal separator in the
seconds value, and states that the preferred option is a comma. Schema-2
appears to express a preference for the period, but it makes no explicit
statement about whether comma is legal, and doesn't mention any deviation
from ISO 8601 in this area.
[AM] We decided to disallow comma as a separator to limit the allowed lexical forms.
 

3. Schema-2 states that "The ˇvalue spaceˇ of dateTime is the space of
Combinations of date and time of day values as defined in § 5.4 of [ISO
8601]." The implication of this is that 2002-02-02T12:00:00Z is a distinct
value in the value space from 2002-02-02T07:00:00-05:00. But if this is so,
then the canonical lexical representation (which is always in UTC with
timezone designator Z) cannot represent all values in the value space.
[AM] The language may not be as clear as possible but the value space represents instances of dateTime regardless of the timezone used.  Thus, in your example above, where you meant to indicate two lexical representations of the same instant of time, both would map to the same value in the value space.  

4. Less importantly, the description of the value space could also be read
as indicating that 12:00:00Z and 12:00:00+00:00 are distinct values, and
that the year 02002 is distinct from the year 2002.
[AM] I'm sure the language could be improved. 

5. Schema-2 states that for a time value, the canonical representation of
midnight is 00:00:00, but it does not make any similar statement for a
dateTime. Does this imply that 2002-02-02T00:00:00Z and 2002-02-01T24:00:00Z
represent distinct values in the value space?
[AM] Perhaps this needs an errata.   

6. Schema-2 states that "The ˇvalue spaceˇ of date is the set of Gregorian
calendar dates as defined in § 5.2.1 of [ISO 8601]." It then says: "Since
the lexical representation allows an optional time zone indicator...".
However, there is nothing in § 5.2.1 of ISO 8601 (at least not the 2000
edition) which suggests that a date can have an optional time zone
indicator, or that suggests how it would be written if it were allowed. If
this deviation from ISO 8601 is deliberate, which it seems to be, it should
surely be flagged in Appendix D3. In fact, this seems to be the only case
where Schema-2 specifies a format that is definitely not allowed by ISO
8601; the other deviations are either restrictions, or things that ISO 8601
permits provided the parties agree.
[AM] This is a deliberate extension to ISO 8601.  Yes, it should have been included in Appendix D3.

7. Why does Schema-2 define no canonical representation of date (unlike
dateTime and time)?
[AM] We should fix that.  It appears to be an oversight.

Similar comments apply to the other data types such as gMonthDay, but I
haven't studied these in detail.

Michael Kay
Software AG

Received on Tuesday, 19 February 2002 09:32:34 UTC