(I thnk this is a permathread for the moment, so posting it to HTML as
well for reference. Is there an issue raised for this, or whatever the
method /du jour/ for identifying questions to be dealt with is?)
On Tue, 10 Mar 2009 01:36:33 +0100, Toby A Inkster
<m...@tobyinkster.co.uk> wrote:
It does seem to me to be a little foolhardy for HTML5 to be defining its
own format for representing dates and times. ISO 8601 is already widely
understood and implemented. Out of the box it is capable of representing
any instant[1] between 10000 BC and 9999 AD, including leap seconds and
any other edge case you choose to think about. Why reinvent the wheel?
In the same way that the W3C Date Time Format note did, it makes sense to
profile ISO 8601 (which is monstrously big as well, and allows lots of
different stuff). Indeed, referring to that (it is probably the most
common format used in metadata communities, who are likely to be
interested in using the element in the first place) would be a step
forward.
That format has some serious limitations for heavy metadata users. In
particular for those who are producing information about historical
objects, from British Parliamentary records to histories of pre-communist
Russia or China to museum collections, the fact that it doesn't handle
Julian dates is a big problem - albeit one that could be solved relatively
simply in a couple of different ways.
The other issue is the one of precision - while you can name a single
year, which will deal with a lot of use cases there are a lot left out
because the precision required is a period. Ranges are included in 8601,
and making a range syntax that handled almost all the relevant use cases
is pretty straightforward.
Enabling these more complex use cases would resolve a lot of people's
uneasiness over the limited utility of the current design. It would also
make it easier to explain to communities who publish or hold large amounts
of metadata how HTML 5 gives them a clear benefit.
An alternative approach of course would be to enable RDFa, since using RDF
it is already simple to deal with these use cases, and the people who have
them very often ahve their data in an RDF-compatible form already.
cheers
Chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
