Re: Date

> >Wow, glad to hear I am not alone in my dislike of the additional Time
Zone
> >Qualifiers-- especially with changing the semantics of the ISO.
>
> In what respect do the XML Schema time zones change the semantics
> of ISO (I guess you mean ISO 8601)?

There are actually several ways-- most of which have good reasoning behind
them-- but are completely inoperable for interchange with specs that are
100% on target with ISO 8601 (yes that was the one...)

http://lists.w3.org/Archives/Public/xmlschema-dev/2001May/0033.html
http://lists.w3.org/Archives/Public/xmlschema-dev/2001May/0037.html

You were actually involved in the second thread... Basically the major
differences included:

Additional +/- representations.
Additional Time Zone Qualifiers for the non-time types (types which are
day/date specific but do not explicitly express time)
Forced usage of the period (.) vs the recommended comma (,) for the sperator
for fractional seconds
Expanded year sections for years greater than 9999
Elimination of truncation types

I think there may have been one or two more that I noticed, but they are
slipping my mind right now.  Please note: I understand most of the reasoning
behind these changes-- my problem is that I cannot say that my application
utilizes "ISO 8601".  Instead I must say it utilizes "ISO 8601 modulo the
above".  Even with the motivation to support SQL types we run into
problems-- in either direction there may be loss in the conversion.  It
strikes me that the date type should not have added or removed anything to
change the semantics of ISO 8601-- perhaps an additional type should have
then been added-- something like xs:expandedDate.

Call me crazy...
Jeff Rafter
Defined Systems
http://www.defined.net
XML Development and Developer Web Hosting

Received on Saturday, 7 July 2001 12:48:21 UTC