W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2001

CORRECTIONS: XML Schema Part 2: Datatypes [2001-03-30].

From: Ian Galpin <g1smd@amsat.org>
Date: Mon, 30 Apr 2001 19:20:01 +0000
To: Paul.V.Biron@kp.org (W3C ~XML ~Paul V. Biron)
Cc: ashokma@microsoft.com (W3C ~XML ~Ashok Malhotra), aron@socrates.Berkeley.EDU (Aron Roberts), www-xml-schema-comments@w3.org (W3C)
Message-Id: <E14uJDa-0004cN-00@scrabble.freeuk.net>

Re: <http://www.w3.org/TR/xmlschema-2/#ISO8601>

  XML Schema Part 2: Datatypes
  W3C Proposed Recommendation 2001 March 30

Several Corrections and Notes:

> G.2 Non-normative

> ISO 8601 
>      ISO (International Organization for Standardization).
>      Representations of dates and times, 1988-06-15. Available at:
>           http://www.iso.ch/markete/8601.pdf 
> ISO 8601 Draft Revision 
>      ISO (International Organization for Standardization).
>      Representations of dates and times, draft revision, 2000. 

The ISO 8601 Standard has been updated. ISO 8601:1988 is no longer
available. The new ISO 8601:2000 was published on 2000-12-21.

See:   http://www.iso.ch/cate/d26780.html

Various copies of the old PDF file version can be found at other locations
on the Internet, though not with the approval of ISO.

There is a copy of the draft ISO8601:2000 available at:

> Lexical representation

> extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century

I really wish that ISO 8601 avoided the 'CCYY' and the word 'Century'. For
Years 2001 to 2099, the CC (from ISO 8601) is '20' but these years are all
in Century '21' in common parlance. The term 'YYYY' is so much better. I
note that the new version ISO8601:2000 has now replaced 'CCYY' with 'YYYY'.

> Lexical representation

>   For example, to indicate 1:20 pm on May the 31st, 1999 for
>   Eastern Standard Time which is 5 hours behind Coordinated
>   Universal Time (UTC), one would write: 1999-05-31T13:20:00-05:00.

> Order relation on dateTime

>   Thus 2000-03-04T23:00:00+03 normalizes to 2000-03-05T02:00:00Z ...

That last example is wrong. The +03 means a Time Zone that is 3 hours ahead
of UTC, so the UTC time must be 2000-03-04T20:00:00Z. Your example would
work if you made the Time Zone on the first date as '-03'  or you swapped
the existing Time Zone indicator between the two dates.

> D.1 ISO 8601 Conventions

> M -- represents a digit used in the time element "month".
> The two digits in a MM format can have values from 1 to 12.

If talking about 'two digits' should it not read '01 to 12'?
(also valid point for Hours, Minutes, Seconds following).

I know thar you clarified it afterwards, with:

> For all the information items indicated by the above
> characters, leading zeros are required where indicated.

but the examples would look more sensible with the zeroes already added.

> 1.1 Purpose

>   <invoice>
>       <orderDate>1999-01-21</orderDate>
>       <shipDate>1999-01-25</shipDate>
>       <billingAddress>
>           <name>Ashok Malhotra</name>
>           <street>123 Microsoft Ave.</street>
>           <city>Hawthorne</city>
>           <state>NY</state>
>           <zip>10532-0000</zip>
>       </billingAddress>
>       <voice>555-1234</voice>
>       <fax>555-4321</fax>
>   </invoice>

I don't like one part of your example: the incomplete representation of the
telephone number. That number will not work if dialled from say Australia,
or even from another US state. Nowhere is there a higher level identifier
that says it is a US number. The area code is missing as well. I will plead
for the number in International Format: '+ 1 909 555 4321', as well as the
mailing address to contain a country identifier from the ISO 3166 standard.
There is a whole real world out there beyond the US border.

Hope the above is useful.







Received on Monday, 30 April 2001 15:21:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:56 UTC