[whatwg] Dates and coordinates in HTML5

[Andy Mabbett]

In message <49A3E9B9.4090300 at lachy.id.au>, Lachlan Hunt
<lachlan.hunt at lachy.id.au> writes

>Andy Mabbett wrote:
>> It seems to me that there are several outstanding, and overlapping,
>>issues for <time> in HTML5, which include use-cases, imprecise dates,
>>Gregorian vs. non-Gregorian dates and BCE (aka “BC“) dates.
>
>The time element was primarily designed to address use cases involving
>contemporary dates.  It doesn't address non-Gregorian calendars or BCE
>dates by design, as it is not really meant for historical dates.

Yes; and it is that narrow approach with which I take issue.

>Probably the most historical dates that it would really be suitably
>optimised for are people's birthdates,

Why? Why are those dates more worthy of being semantically marked-up
than, say, the date of the sailing of the Mayflower, of the birthdate of
Caesar?

[...]
>These issues have all been discussed before, either here in the whatwg
>or on public-html, and so I won't go into great detail.

I did make a point of saying:

        I've read up on what prior discussion I can find on the list;
        but may have missed some. I'll be happy to have anything I've
        overlooked pointed out to me.

>> First, though, I should like to make the observation that, while
>>hCalendar  microformats are most commonly used to allow event details
>>to be added  to calendar apps, and that that use case drove their
>>development, they  should not be seen simply as a tool to that end. I
>>see them, and hope  that others do, as a way of adding semantic
>>meaning to mark-up; and  that's how I view the “time" element, too.
>>Once we indicate that the  semantic meaning of a string of text is
>>date, it's up to other people to  decide what they use that for — "let
>>a thousand flowers bloom", as the  adage goes.
>
>I think this is a philosophical difference in approach from that which
>we used in developing the time element, and other features in HTML5.
>Semantics for the sake of semantics are not, and should not be, a
>design goal.

I am not proposing semantics "for the sake of semantics"; I am showing
that the semantics are already deployed, and that once deployed, the
potential use cases are more varied than the current examples.

[...]
>While it may seem like a logical step to go from supporting those real
>use cases, to supporting theoretical cases involving BCE dates, Julian
>calendars, leap seconds and whatever else, this actually only ends up
>introducing unnecessary complexity.

The use-cases I gave are not "theoretical".

Is the complexity really "unnecessary", or are we just putting off a
difficult piece of work?

>> Use-cases for machine-readable date mark-up are many: as well as the
>>aforesaid calendar interactions, they can be used for sorting; for
>>searching...
>
>Yes, but the question is, are any of the use cases involving historical
>dates really worth addressing with the time element?  If so, what are
>those use cases and why are they significant enough?

The uses cases are in the paragraph you only quote partially, above. I
think they are all worth addressing (indeed, I think it would be
foolhardy not to), and I'm not alone in thinking so. How do you propose
to measure their worth objectively?

>> hCalendar microformats are already used to mark up imprecise dates
>> ("June 1977"; "2009"). ISO8601 already supports them. Why not HTML5?
>> Though care needs to be taken, it's even possible to mark up words like
>> “today" with a precise date, if that's generated real-time, server-side.
>
>What are the use cases for marking up such imprecise dates?  Are people
>using hCalendar for such purposes?

Yes, as I say in the text you quote; and on the sites I gave in my
introduction (and unambiguously supported by the hCalendar specification
and ISO8601). Use cases as above.

>> The issue of non-Gregorian (chiefly Julian) dates is a vexing one

>>It is not the job of the HTML5 working group to
>> solve this problem; but I think the group should recognise that at some
>> point a solution must be forthcoming. One way to do so would be allow
>> something like:
>>          <time schema="[schema-name]" datetime="[value]">[date in
>>plain
>>         text]</time>
>
>Developing such a solution without having clear use cases and a good
>explanation of why addressing those use cases is worthwhile, is not a
>good use of our time.

Again, use cases have been given. Why do you feel that they are not
clear?

>Even more so because you're trying to make room for a hypothetical
>solution of marking up Julian dates that doesn't yet exist.

No; I'm proposing a solution which allows non-Gregorian date schemas to
be used.

>> As for BCE dates, they're already allowed in ISO 8601 (since there was
>> no year 0, the year 3 BCE is given as -0002 in ISO 8601). I see no
>> reason why they should be disallowed in <time> elements in HTML5.
>
>Because allowing them requires additional effort, such as changes to
>the parsing requirements, for which there is little to nothing gained
>in practice due to a lack of compelling use cases.

Again: why are the use cases given not acceptable to you?

>> Coordinates
>>  Another abuse of ABBR in microformats for coordinates:
>>          <abbr class="geo" title="52.548;-1.932">Great Barr</abbr>
>>  Bruce and I agree that this could be resolved, and HTML5 usefully
>> extended, by a “location" element:
>>          <location latitude="52.548" longitude="-1.932">Great
>>         Barr</location>
>
>I'm not familiar with the use cases for the geolocation microformat,
>nor am I aware if there even are any.  So I will not comment on this.

There are many million 'Geo' microformats published in the wild, with
support in several browsers/  plugins and on-line apps. Publishers
include Google, Wikipedia and Flickr:

        <http://microformats.org/wiki/geo-examples-in-wild>

>> Using the “schema" attribute shown above, for non-Gregorian dates, we
>> can extend that for Martian, Lunar (and eventually other bodies):
>>          <location schema="moon" latitude="52.548"
>>         longitude="23.47297">Sea of Tranquility</location>
>
>What's the use case for this?  Why would most people need to mark up
>lunar co-ordinates?

For example: to allow such points to be easily found on maps, or in
tools like Google Earth - the same as can be done presently for
terrestrial coordinates, using "Geo" microformats.

Also of note is that NASA plans to begin constructing a permanent
presence on the Moon (which will be referanceable by lunar coordinates;
as will each of the places which they will then explore) in 2019 -
that's three years before 2022 ;-)

>  Are astronomers really asking for such facilities to be included in
>HTML?

The Astrogeology Team of the  U.S. Geological Survey have expressed
interest. But astronomers are far from the only publishers of such data.

>  Would we really be addressing their needs by doing so?

Apparently so.

>> Now all we need to do is to work-around the abuse of ABBR for durations,
>> in the draft hAudio microformat:
>>          <abbr title="PT3M23S">3 minutes 23 seconds</abbr>
>
>What's the use case?

That was a light-hearted comment, but see, for example, the duration
properties in:

        <http://microformats.org/wiki/haudio>
and:
        <http://microformats.org/wiki/hrecipe>

More seriously, a more widely-scoped "measurement" element, capable of
taking, for example, values of "duration", "length", "mass",
"temperature", etc.; and a value; and perhaps a schema (defaulting to
SI), would perhaps be more useful. Use cases are microformats, plus
translation, automated conversion, sorting, etc.

-- 
Andy Mabbett