Re: [whatwg] <time>

Hi Jim,

On Thu March 2009 at 12 01:04:22 PDT, Jim O'Donnell wrote:
> On 12 Mar 2009, at 02:53, Robert J Burns wrote:
>
>> Since you keep repeating the following example (by copy and paste?)
>> I will mention that you have the year wrong in one place or the
>> other (1731 and 1732). Dates only diverge by years between Julian
>> and Gregorian many millions of years in the future or past or in BC
>> if using eras that insert a zero year into the calendar. Since
>> we're not even proposing the ability to change eras, we should
>> assume the same era for both calendars (in any event that only
>> applies to BCE/BC dates).
>
> I used that example since it's the Julian date example used in the
> TEI docs for the <date> element. Happy to give other examples but
> that one seems to nicely demonstrate historical dates. Just one
> correction. 1 January was not adopted as the start of a new year
> until 1752. Hence Jan, Feb, Mar 1731 in the Julian Calendar are Jan,
> Feb, Mar 1732 in the calendar we use now (Gregorian).

This actually raises a further complication in establishing years:  
that of the changes to the start of the year in various localized  
versions of a calendar. While I think one could make a case for a  
generic Julian calendar starting on January 1st, using changes like  
you cite for 1752 is a specifically British Julian calendar (and only  
the British Julian calendar). This indicates that supporting metadata  
such as that level of specificity would require several or even a  
dozen Julian calendar keywords (or some other convention such as  
Julian-uk, Julian-ru, etc.). This complication may apply to other  
calendars as well, but probably not to the extent of the Julian, which  
was dispersed worldwide without a continuing central authority.

> On the issue of the calendar attribute, I suggested that as it's
> already present in TEI-encoded documents. TEI is in wide use by
> archives and libraries to digitise historical text and the calendar
> attribute is familiar to TEI authors. Obviously, the semantic info
> captured by TEI is lost when documents are transformed to HTML in
> order for publication online. I thought it would be useful to retain
> this semantic information in HTML but, as I also said, it isn't
> essential,

I did follow the suggestion as derived from TEI and I think it could  
be useful. However, I think an approach that drew on RDFa would allow  
the data to be preserved in HTML. In that way the date can be placed  
in the 'content' attribute and the 'datatype' attribute can indicate  
the form of the date in that attribute. However, the HTML5 'time'  
element allows prose rather than structured date information to be  
placed in the contents of the time element. So I think a more faithful  
treatment of the TEI data in HTML is to have the 'calendar' or  
'datatype' attribute refer to the 'content' or 'datetime' attribute  
value and not the 'time' element's contents (HTML simply has  
differences from TEI that make more sense to apply qualifiers to the  
accompanying attributes and not the elements contents). Then all of  
the information is preserved. Even if an author wanted to include  
converted date information, the author could provide nested time  
elements each with a different calendar and corresponding date  
indicated. The contents of the element could then be any prose the  
author chose.

For example:

<time content="1917-11-7"><time datatype='html:Julian-ru'  
content="1917-10-25">On the day of the October revolution</time></ 
time> ...

In this way all of the metadata can be preserved and provided in  
whatever level of richness the author desires (even when it is  
technically redundant). The element's prose contents can also contain  
whatever the author wants. Eventually UAs, plugins, CSS mechanisms,  
and other handlers could be created to easily perform supported date  
conversions for users. In that case the nested 'time' elements become  
superfluous, but still possible for targeting legacy UAs or to provide  
author preferred conversions.

Take care,
Rob

Received on Thursday, 12 March 2009 09:09:01 UTC