- From: Toby Inkster <tai@g5n.co.uk>
- Date: Sat, 3 Dec 2011 16:41:13 +0000
- To: tantek@cs.stanford.edu
- Cc: "John Cowan" <cowan@mercury.ccil.org>, "John Cowan" <cowan@ccil.org>, "Jeni Tennison" <jeni@jenitennison.com>, www-xml-schema-comments@w3.org, "HTML Data Task Force WG" <public-html-data-tf@w3.org>, "RDFa WG" <public-rdfa-wg@w3.org>, public-html-xml@w3.org
On Mon, 21 Nov 2011 09:51:07 +0000 "Tantek Çelik" <tantek@cs.stanford.edu> wrote: > months and years durations were deliberately excluded due to > 1. Lack of documented use-cases/publishing examples for them. > 2. Precedent. Explicit exclusion of month and year durations from > iCalendar (which was the basis for hCalendar, which was a key design > driver for the time element). I would posit that the use cases for <time> are a superset of those for hCalendar/iCalendar. While one is unlikely to want to add the Hundred Years War to their calendar, it might still be useful to mark up its duration with a <time> element on a web page. <time value="P116Y">116 years</time> seems infinitely preferable to <time value="P42340D">116 years</time> which is not only unruly, but implies a level of precision that seems unwarranted. ISO 8601 gives us a nice, standard notation for durations. I'd support subsetting it if there were massive disadvantages to adopting the full notation, but I don't think these disadvantages exist. I've written a parser for ISO 8601 durations before, and I can't recall the requirement to differentiate between 'M' before and after the 'T' being especially onerous to implement. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk>
Received on Saturday, 3 December 2011 19:54:25 UTC