Re: [whatwg] time
On 16 Mar 2009, at 20:10, Tom Duhamel wrote:
It seems that pretty much everyone agrees on this:
- Allow the use of an alternate calendar, but only Gregorian is
required to be understood by user agents
- We only require the user agent to display dates; they are free to
do more if they like (conversion, ...) but are not required to.
- Calendar is specified in a new attribute ('calendar' or something
similar) and the value of 'datetime' attibute is specified in the
calendar specified by that new attribute
- If 'datetime' attribute is missing, try to interpret the content
as an ISO date. User agent could print the content as is, or print
in a more friendly way if desired (in case it was successfully read
as a valid ISO date).
- If content is missing, print 'datetime' attribute (in a friendly
way, if desired and set by user, or simply as is if unable to do
better)
- If both content and datetime are present, print content on page
and show a representation of the date in datetime with a mechanism
such as a tool tip
This seems overly complex to me.
Can we follow existing practice from TEI ie. datetime may only be
Gregorian and no other calendar - calendar (if present) identifies
the calendar in the original text (analogous to the way the HTML lang
attribute indicates the language of the enclosed text).
So, a date marked up in a TEI document as
date calendar =julian value=1547-02-2818th Feb. 1546/date
transforms to the following HTML
time calendar=julian value=1547-02-2818th Feb. 1546/date
My reasoning here is that TEI is already in widespread use, authors
familiar with it will expect the same markup practices in HTML and
one of the largest uses for historical dates as time elements will
be transformation of existing TEI documents to HTML.
It seems dangerous, to me, to adopt a whole new standard for
historical dates in HTML when there is an existing standard in wide use.
Essentially I'm asking that the spec for time mirror the existing
spec for date to make it compatible with historical texts:
http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html
Regards
Jim
Jim O'Donnell
j...@eatyourgreens.org.uk
http://eatyourgreens.org.uk
Re: [whatwg] time
On 13 Mar 2009, at 16:19, David Singer wrote: Can we drop this topic? Apart from suggesting a) that the fully delimited date format be required (extended format); b) that year and before be allowed; c) that parsing the body text as 8601 may be dangerous if it's notated the same way but not (possibly proleptic) Gregorian; I agree, with the addition of time periods denoted by two datetimes seperated by a / eg. 1914/1918. This would bring HTML5 in line with existing authorship practices in use in TEI. Authors will be able to encode any historical date be it Julian, Roman, Mayan, Chinese etc by continuing to do what they're already accustomed to doing - publishing the machine readable date as a proleptic Gregorian date. The proposed schemes for alternative calendars seem like a red herring to me, since noone in practice encodes machine readable versions of alternative calendars when digitising a text. Regards Jim Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens http://twitter.com/pekingspring
Re: [whatwg] time
On 13 Mar 2009, at 10:33, Mikko Rantalainen wrote: This is already a solved problem in the Text Encoding Intiative (TEI). The value of a date/time is encoded in the Gregorian calendar, using ISO8601. The calendar attribute is used to indicate the calendar of the original, written date enclosed in the tags. I'm not sure why the original calendar would need to be indicated in the 'calendar' attribute. It does not matter for the 'value' or software in general, if I've understood correctly. If the 'value' is always in Proleptic Gregorian calendar, it's all the software needs to know. Hello, the usual use of TEI is encoding historical papers for digital preservation eg. digitising large archives of correspondence or literature. The calendar attribute exists to preserve semantic information in the digital version of a paper document. I was interested to know whether there was value in preserving such information in HTML also, since digital versions of historic documents are published on the web as HTML. I understand, though, that HTML should not become a grab bag of features from other SGML or XML vocabularies so I wouldn't push for a calendar attribute on time if it isn't generally useful or if I'm the only person that wants it. Regards Jim Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk
Re: [whatwg] time
Hi Robert 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). 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, Regards Jim Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens http://twitter.com/pekingspring
Re: [whatwg] time
Hi Andy On 12 Mar 2009, at 21:46, Andy Mabbett wrote: In message caaf25cf-1fbe-494c-8361-e6811b6c5...@googlemail.com, Geoffrey Sneddon foolist...@googlemail.com writes Ultimately, why is the Gregorian calendar good enough for the ISO but not us? I'm sure plenty of arguments were made to the ISO before ISO8601 was published, yet that still supports only the Gregorian calendar, having been revised twice since it's original publication in 1988. Is there really any need to go beyond what ISO 8601 supports? What were the use-case(s) for ISO8601? If merely the exchange of calendar information, it's unlikely that it took account of the pre- Gregorian/ BCE/ imprecise situations under consideration here. ISO8601 is already used by historians to mark up dates pre 1582 or BCE, or even uncertain dates. The proleptic Gregorian calendar is fine back to something like -1BC, which covers pretty much all of recorded history. Uncertain dates of the form we deal with on a day- to-day basis in museums, like 'circa 1920' or 'late 20th century' can be encoded as '1915/1925' or '1951/2000' using ISO8601. I think uncertain times encoded as ISO8601 date ranges in the datetime attribute will handle any reasonable markup of a historical date. Anyone who has a weird use case that falls outside this can fall back on RDFa. Does anyone see a case for identifying the calendar of the date in the running text, or is that just me wearing my pedantic, semantic history markup hat? Jim Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens http://twitter.com/pekingspring
Re: [whatwg] time
On 11 Mar 2009, at 04:46, Leif Halvard Silli wrote: This is already a solved problem in the Text Encoding Intiative (TEI). [ ... ] date calendar=Julian value=1732-02-22Feb. 11, 1731./date [ ... ] We can't change the author's original written dates, but it would be useful to normalise documents using the Julian calendar to proleptic Gregorian dates. Yes, the draft needs to clear up the (mis)understanding that time requires authors to place Gregorian dates in the original. If the calendaric meta information should be available to human consumers, then then @title seems like a better place. The draft could recommend how to use @title for time. How about something like time calendar=Julian value=1732-02-22 title=22 February 1732Feb. 11 1731/time, where title and calendar are optional? Regards Jim Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens http://twitter.com/pekingspring
Re: [whatwg] time
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. 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-22Feb. 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-22Feb. 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. I'm proposing that datetime accept ISO8601 dates as per the existing W3C datetime profile. ISO8601 dates may only use the Gregorian calendar. 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. That shouldn't add any extra load to datetime parsers - they only need to be able to understand Gregorian ISO8601 dates. 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. Regards Jim Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens http://twitter.com/pekingspring
Re: [whatwg] time
Hi David, On 10 Mar 2009, at 17:03, David Singer wrote: The trouble is, that opens a large can of worms. Once we step out of the Gregorian calendar, we'll get questions about various other calendar systems (e.g. Roman ab urbe condita http:// en.wikipedia.org/wiki/Ab_urbe_condita, Byzantine Indiction cycles http://en.wikipedia.org/wiki/Indiction, and any number of other calendar systems from history and in current use). Then, of course, are the systems with a different 'year' (e.g. lunar rather than solar). And if we were to introduce a 'calendar system designator', we'd have to talk about how one converted/normalized. This is already a solved problem in the Text Encoding Intiative (TEI). The value of a date/time is encoded in the Gregorian calendar, using ISO8601. The calendar attribute is used to indicate the calendar of the original, written date enclosed in the tags. eg. from the TEI docs for dates and times date calendar=Julian value=1732-02-22Feb. 11, 1731./date I suggested that the calendar attribute be adopted in HTML5, as it would be useful to those of us who mark up historical texts in HTML. We can't change the author's original written dates, but it would be useful to normalise documents using the Julian calendar to proleptic Gregorian dates. See http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html and the associated guidelines on publishing dates and times http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA Adding a range construct to 8601, or having a range construct ourselves using 2 8601 dates, seems like something we could ask for or do. 8601 already allows ranges. Simply seperate two ISO8601 dates with a / eg. 1595-11/1596-02. Regards Jim Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens http://twitter.com/pekingspring
Re: [whatwg] Historic dates in HTML5
On 5 Mar 2009, at 15:17, Greg Houston wrote: Personally, I think it would be an improvement to the datetime attribute if it was valid for at least - - : p ... For these events to take place within a three week or so period is simply impossible. The time datetime=-0004-03-13eclipse/time cannot be the one written in the records of Josephus./p I agree that this would be an improvement, since it would make time compatible with hCalendar by using ISO8601 for datetime. By remarkable serendipity, Paul Tarjan posted a presentation about searchmonkey today http://www.slideshare.net/ptarjan/semantic-searchmonkey It mentions searching the web by date, where that information is available. So I would say a key use case for marking up historic dates is searching large archives by date eg. searching the National Maritime Museum archive for Elizabethan Navy records dating from 1595. Wikipedia uses the date-time design pattern, from microformats, to mark up historic dates using ISO8601. In addition, TEI is widely used by archives and libraries to mark up texts, including ISO8601 dates (http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html). Since authors are already publishing dates online, surely HTML5 should accept all ISO8601 dates rather than a limited subset, which requires additional processing on the part of authoring and publishing software to filter out valid dates that are invalid HTML5. Regards Jim Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens http://twitter.com/pekingspring
[whatwg] Historic dates in HTML5
Hello, Apologies for coming in late but Bruce Lawson pointed me in the direction of this discussion I had some comments about dates in HTML5. Lachlan Hunt wrote: 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. Probably the most historical dates that it would really be suitably optimised for are people's birthdates, which, for people alive today, don't really extend back beyond the early 20th century, with very few exceptions. Has any consideration been given to using the time tag in the same manner as the date element from TEI to mark up dates, particularly the calendar attribute to indicate non-Gregorian calendars? (see http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html) I ask because one of the sites I look after is the National Maritime Museum archive search, which includes ~70,000 records dating from the 16th century to present. Of those, around 3,500 predate the Gregorian calendar and have, presumably, Julian dates: http://is.gd/lFrh It would be useful to mark up these dates as dates in the HTML versions of the catalogue records. However, from what Lachlan Hunt has said, it seems the time tag in HTML5 can't be used to do this. This then leads to a situation where some dates on the web can be marked up, semantically, as dates but others cannot, which seems somewhat ridiculous really. Is there any suitable markup in HTML5 for dates in digitised documents from museums, libraries and archives? Regards Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens http://twitter.com/pekingspring
