Re: Date and dateTime formats do not allow some valid ISO 8601 values (XML Schema bugzilla #3040)

Dear Mr. Hockaday:

Thanks for the thoughtful exposition of your ideas concerning ISO
date/time formats and how you'd like to see XML Schema change to
accommodate more of them.  I'd like to explain why we think we must
decline your request.

Before launching into the explanation, I should mention that some
members of the WG agree that what you're asking for would be helpful
[1].  However, the fact that techniques exist that can help minimize the
issues (such as transforming for presentation) takes a lot of energy out
of any impetus to change date/time datatypes from the way they are now.

Our position rests on these ideas:
1) XML Schema consistently tries to narrow the scope of allowed formats.
This narrowing is obviously a tradeoff that benefits the builders of
parsers [2].
2) datatypes in XML schema  each define a set of lexical representations
mapped to a value space, and the XML Query specification currently
relies on these mappings.
3) canonicalization and "round-tripping" issues are nettlesome in the
current proposal, and would become more difficult .

It's not that we couldn't resolve or negotiate all of these issues
eventually.  It's that we have found that date/time issues take an
inordinate amount of consideration, and that the solution we have now
seems to satisfy most users.  Over the years, the WG has considered a
lot of proposals for helpful datatypes, and at the end of deliberations
we had to agree to exclude them because they presented a significant
additional burden (both on the spec and on writers of parsers) while
providing only limited improvement in the lives of our users. And at
this point introducing any new primitive types (not just those having to
do with date and time) would cause unavoidable difficulties in the QT
specifications, specifically XML Query, XSL, XPath 2.0, and the Data
Model. 

We hope you accept our position.  We deeply appreciate the obviously
careful reading you've given our work, and we hope you'll continue to
care enough to do so in the future.  

Best regards,
David Ezell
On behalf of the XML Schema Working Group

[1] In fact, one point in the rationale (though not the winning one) for
the inclusion of precisionDecimal in the latest working draft of
Datatypes was based in part on your "false indication of accuracy"
argument.  In the end, precisionDecimal was included to better conform
to IEEE 754, and the WG decided that accuracy issues could be handled by
complex types designed for the task.  
[2] On the other hand, having lots of parsers on the market that can
interoperate benefits users.