Re: [whatwg] <time>

Hi Jim,

On Wed Mar 11 2009 at 15:13:57 PDT, Jim O'Donnell wrote:
>
> On 11 Mar 2009, at 08:54, Robert J Burns wrote:
>
>>
>>
>>>>  Authoring tools can be used to convert from other formats to
>>>>  Gregorian.
>>>
>>
>>>  And in that regard, it should be very relevant to have a calendar
>>>  attribute.
>>
>>  Or reuse the RDFa datatype attribute with new calendar system
>>  keywords.
>>
>
>

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'm not sure that would work, or rather that you would need the
> complexity of RDFa for something as simple as a change of calendar.
> My example of a Julian date in 1732
> <time calendar="Julian" datetime="1732-02-22">Feb. 11 1731</time>,
> (from http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html)
> would then be, I think, in RDFa
> <time datatype="GregorianDate" content="1732-02-22">Feb. 11 1731</ 
> time>
> since datatype describes the format of the content attribute, which
> is always a proleptic Gregorian date. So you'd lose the semantic
> information that the marked-up date is in the Julian calendar.


Using RDFa instead of a new calendar attribute leaves the complexity  
of the markup unchanged. In the case of Gregorian no other attributes  
other than the 'content' attribute are even necessary.

As for your proposed 'calendar' attribute to indicate the calendar  
used in the element contents, I don't think that is a good idea. It  
needlessly complicates the markup and I feel it is ill-advised to  
include an attribute that tells a reader how to interpret the  
contents. The calendar for the contents should be clear from the  
context of the reading without a machine readable attribute. However  
the machine readable attribute ('datetime' or 'contents') does need  
further machine-readable attributes to qualify the machine  
interpretation (unless we restrict it to Gregorian only).

> I'm proposing that datetime accept ISO8601 dates as per the existing
> W3C datetime profile. ISO8601 dates may only use the Gregorian
> calendar.

I understand that. But I'm suggesting that many use cases have a need  
for non-Gregorian dates and would benefit from some of the same  
implementation incurred costs of implementing Gregorian only dates. I  
don't see any reason why we should arbitrarily restrict ourselves to  
ISO 8601 for HTML. At the very least, HTML5 should provide additional  
criteria to enhance ISO 8601 to support proper proleptic Gregorian  
dates (without inserting a zero year).

> In addition, it would be useful, but not essential, in
> describing the semantics of historical dates to have an attribute, as
> per TEI, identifying the calendar in use in the text itself.

Again, I don't think that adding attributes that change the meaning of  
content without accompanying default presentation is a good idea. The  
human reader should basically understand the calendar specified from  
the surrounding prose context. And in terms of machine consumers, It  
seems motivated only by trivial curiosity to catalogue what calendar  
some author is referring to in inline content. How would such data get  
used?

> That
> shouldn't add any extra load to datetime parsers - they only need to
> be able to understand Gregorian ISO8601 dates.

I think we could enhance ISO 8601 in a way that allowed support for  
non-Gregorian calendars but also allowed implementations to utilize  
the same parsing algorithms already in place. In other words allow  
yyyyyy-mm-dd (optionally omitting the leading yy) to indicate the  
year, month and date of the month in any calendar that uses those  
concepts (most of them). This would exclude the Julian Day and  
Modified Julian Day calendars though we could even add support for  
those as decimal numbers (e.g., "<time datatype='JulianDay'  
content='2454901.5'.>Wednesday, March 11, 2009</time>"). Much of the  
parsing is then handled by existing algorithms regardless of calendar.  
Implementation support for additional calendars would only be needed  
for implementations that wanted to compare dates or convert calendars  
dates between various calendars for presentation or other purposes  
(which is needed even for Gregorian only support in content).

> Expanding the datetime or RDFa content attributes to contain non-
> Gregorian dates would be an unnecessary headache and, frankly, more
> trouble than it's worth.

In comparing the trouble of implementing, I think support for non- 
Gregorian dates is of much greater use than the extra trouble of  
implementing heuristic-style date parsing in contents as proposed in  
the current draft. Some dates are not readily translatable to  
Gregorian dates, but would still benefit from markup like that offered  
in RDFa and the 'time' element. UAs would only compare dates where  
they had implemented the designated calendar. For Gregorian dates this  
all simplifies to the same thing proposed, but allows UAs room to add  
other support (particularly UAs targeting communities commonly using  
non-Gregorian dates).

Take care,
Rob