On Thu, Dec 10, 2009 at 4:09 AM, Hugh Guiney <hugh.gui...@gmail.com> wrote: > My own use case involves marking up years of publication for documents I > have created, to be displayed in an online resume that can be sorted by > date. I do not necessarily have the original timestamps for every file, yet > I can recall the years in which they were published. In this case, the year > "2005", for instance, is semantically distinct from the numeral "2005", and > though the difference can be inferred from context by a human it can not by > a machine, hence why things like <time>2005</time>, or <time > datetime="2005">4 years ago</time> would be useful here. But under the > current specification, these uses are invalid, meaning I'd only be able to > specify exact dates with meaningful language, as in <time > datetime="2005-01-01">2005</time>, and hack around it for inexact dates with > non-semantics like <span class="datetime">2005</span>.
Are you planning on using the information in <time> to *do* the sorting? That is, when someone chooses "sort by date", do you have scripting that searches in each section for a <time> and extracts the date to determine where in the order it should go? > The way I see it, if we can mark up abbreviations without having to expand > them fully, or even at all (<abbr>XSLT</abbr>, <abbr title="XSL > Transformations>XSLT</abbr>, and <abbr title="eXtensible Stylesheet Language > Transformations>XSLT</abbr>, or even <abbr title="cat">XSLT</abbr> are all > valid) we should be able to mark up datetimes without having to expand them > fully. Fairness isn't a justification for putting anything in the spec, fortunately. Each piece of the spec has to justify itself. > But don't take my word for it. I'm sure these articles have been mentioned > here before, but Eric Meyer > <http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/> and PPK > <http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html> have > also voiced support for a less-restrictive <time> (Hixie has at least seen > the former > <http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/#comment-475378>, > though there was no further discussion with him about the issue there.) I agree with Meyer on the first one. That's a useful case. In addition, <time>'s usefulness in Microdata is somewhat impaired by its inability to mark up months or years. These are by far the most common 'fuzzy dates' that one would have to mark up for embedded metadata. Their lack means that vocabularies need to structure themselves to take two dates per real 'date', to allow such fuzziness, which means that date *ranges* would need *four* dates specified. That's just silly. However, the second one isn't quite an argument for expanding time. It's an outlining of, *if* we decide that we want <time> to be useful for *all* dates, how we should go about doing it. ppk recognizes that such an approach may not be what the spec wants. ~TJ