RE: Lexical and canonical representations of dateTime, et al.

Hi Ashok,

     Thanks for your responses.  I've added additional comments after your
comments below.  Sorry if I've misunderstood anything.

Thanks,

Henry
------------------------------------------------------------------------
Henry Zongaro      XML Parsers development
IBM SWS Toronto Lab   Tie Line 778-6044;  Phone (416) 448-6044
mailto:zongaro@ca.ibm.com


"Ashok Malhotra" <ashokma@microsoft.com>@w3.org on 2001/03/22 12:03:34 AM

Please respond to "Ashok Malhotra" <ashokma@microsoft.com>

Sent by:  w3c-xml-schema-ig-request@w3.org


To:   Henry Zongaro/Toronto/IBM@IBMCA, <w3c-xml-schema-ig@w3.org>,
      <xmlschema-dev@w3.org>
cc:
Subject:  RE: Lexical and canonical representations of dateTime, et al.


See comments interspersed in your test below.
Ashok

-----Original Message-----
From: zongaro@ca.ibm.com [mailto:zongaro@ca.ibm.com]
Sent: Wednesday, March 21, 2001 11:25 AM
To: w3c-xml-schema-ig@w3.org
Subject: Lexical and canonical representations of dateTime, et al.



Hello,

     I posted the following to xmlschema-dev@w3.org yesterday, but I
thought I should cross-post here, in case anyone on this list isn't
monitoring the other.

Thanks,

Henry
------------------------------------------------------------------------
Henry Zongaro      XML Parsers development
IBM SWS Toronto Lab   Tie Line 778-6044;  Phone (416) 448-6044
mailto:zongaro@ca.ibm.com


---------------------- Forwarded by Henry Zongaro/Toronto/IBM on
2001/03/21
02:24 PM ---------------------------

Henry Zongaro/Toronto/IBM@IBMCA@w3.org on 2001/03/20 11:59:00 AM

Please respond to Henry Zongaro/Toronto/IBM@IBMCA

Sent by:  xmlschema-dev-request@w3.org


To:   xmlschema-dev@w3.org
cc:
Subject:  Lexical and canonical representations of dateTime, et al.



Hello,

     I had some questions/comments about the lexical representation of
dateTime in the latest Schema Datatypes PR.

     Section 3.2.7.1 of the PR
(http://www.w3.org/TR/xmlschema-2/#dateTime)
states that

   This lexical representation is the [ISO 8601] extended format
   CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year,
   "MM" the month and "DD" the day, preceded by an optional leading "-"
   sign to indicate a negative number. If the sign is omitted, "+" is
   assumed. The letter "T" is the date/time separator and "hh", "mm",
   "ss" represent hour, minute and second respectively. Additional
   digits can be used to increase the precision of fractional seconds
   if desired i.e the format ss.ss... with any number of digits after
   the decimal point is supported. To accommodate year values greater
   than 9999 additional digits can be added to the left of this
   representation. The year 0000 is prohibited.

   This representation may be immediately followed by a "Z" to indicate
   Coordinated Universal Time (UTC) or, to indicate the time zone,
   i.e. the difference between the local time and Coordinated Universal
   Time, immediately followed by a sign, + or -, followed by the
   difference from UTC represented as hh:mm.

1) Unlike the definition of number (3.2.3), this definition doesn't
specify
the minimum number of additional year digits nor the minimum number of
additional digits in the fractional portion of the seconds that needs to
be
supported by a processor.  Does a processor really need to be prepared
to
handle an arbitrary number of digits?  Obviously this can have a
significant effect on an implementation.
AM>> There have been a lot of diffrent requirements for this.
AM>> Scientists want very accurate fractional second values.
AM>> Use a decimal number to represent the seconds part.

HZ>> I don't object to supporting very accurate fractional numbers of
HZ>> seconds; my only question is whether a processor needs to be
HZ>> prepared to support an *arbitrary* number of digits.  The
HZ>> definition of "number" permits a minimally-conforming processor
HZ>> to support as few as 18 digits, but there is no similar "out" for
HZ>> a processor with respect to the number of digits in the
HZ>> fractional portion of the seconds, nor in the number of digits in
HZ>> the year.

2) Is the ":mm" portion of the timezone required in the lexical
representation?  For example, is 2001-03-19T10:20:00-05 a permissible
lexical representation?  The second paragraph quoted above seems to
imply
that it is required, but some of the examples show only the hours
portion
of the difference from UTC when ":mm" is ":00".  If the ":mm" can be
omitted, is it required in the canonical representation, or must it be
omitted from the canonical representation when ":mm" is ":00"?
AM>> mm is not required in the lexical representation.
AM>> It is required in the canonical representation.

HZ>> The specification will probably need to be corrected in the
HZ>> future to make that clear, as that's not stated today - unless
HZ>> I've missed text that already makes that clear.

3) ISO 8601 specifies that 24:00:00 of one day is the same as 00:00:00
of
the following day.  Which is the permitted form in the canonical
representations of the various types?
AM>> Both are acceptable.

HZ>> The definition of canonical lexical representation requires there
HZ>> to be a one-to-one mapping between the canonical lexical space
HZ>> and the value space.  Because 2001-03-21T24:00:00Z maps to the
HZ>> same value as 2001-03-22T00:00:00Z, I don't believe they can both
HZ>> be permitted to be canonical lexical values.

4) Are leading zero digits in a year permitted in the lexical
representation beyond the four required digits?  For example,
0012001-03-19T10:20:00.  I didn't notice any restriction against that.
If
that would be permitted, should it be restricted in the canonical
representation?  Sorry if this is described in the revision of ISO 8601;
I
don't have a copy.
AM>> Yes, they are

HZ>> So then I assume that the leading zero digits beyond the last four
HZ>> digits will need to be restricted in the definition of the
HZ>> canonical representation.

Thanks,

Henry
------------------------------------------------------------------------
Henry Zongaro      XML Parsers development
IBM SWS Toronto Lab   Tie Line 778-6044;  Phone (416) 448-6044
mailto:zongaro@ca.ibm.com

Received on Thursday, 22 March 2001 14:34:29 UTC