Re: ISO 8601 anyone?? And more on Parties.

["William J. Kammerer" <wkammerer@foresightcorp.com>]

Sharon Kadlec says "It's the CONTENT [of dates or times that's
important], not the format - label it correctly and we'll put it where
it belongs for our purposes."

Absolutely!  It's up to the recipient to interpret the normalized
content - and then display the date, time or dateTime any which way he
wants.  Therefore, since a dateTime can always be normalized as an ISO
8601 extended date-time, there's no need to send along information on
how to decode it.  As I noted earlier, the spreadsheet catalog has "date
time.format.text code" defined as "[Using] values from ISO 8601."  There
are no "codes" in ISO 8601.

This isn't the same situation as with the EDIFACT C507 DATE/TIME/PERIOD
composite where the date and time can be transmitted over the wire as
DDMMYY or DDMMCCYY or CCYYMMDD or YYMMDDHHMMSS, etc. etc. With the
dateTime XML Schema Data Type, you have no choice:  it must be
CCYY-MM-DDThh:mm:ss (with optional trailing -  and unambiguous - time
zone stuff or Z for universal time) - no 'ifs,' 'ands' or 'buts."

Even putting aside the input format considerations, EDIFACT D.E. 2379
(Date or time or period format code) was used to indicate whether you
had a Date, a Time, a DateTime, a Period,or a duration, etc. etc. - as
to say: it was comingling data types. These are handled with separate
datatypes in XML Schema: viz. a date (e.g., 1999-05-31), a time (e.g.,
13:20:00), a dateTime (e.g., 2000-03-04T23:00:00+03), or a duration
(e.g., P1Y2MT2H), respectively. These are conceptually separate basic
core components (even dateTime could be considered basic - it needn't be
merely a date and time aggregated together).

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"accelerating time-to-trade"