Re: <time> values in HTML5

On Mon, 2011-11-21 at 16:46 +0000, Tantek Çelik wrote:
> [..]

>  I'd suggest that for the purposes of transcoding to existing
> type/value systems (eg XML Schema 1.1) that the new values:
> 
> 1. Be treated as a simple string
> 2. Provide input to the next iteration of such existing type systems
> (eg XML Schema 1.2). Thus I would not hold back or modify any (even
> imminent) CR drafts.

I wouldn't hold your breath for a W3C XML Schema 1.2 in the next 5 to 10
years... for sure the current WG isn't chartered to do that work.
> 
> BTW as a point of W3C process, I don't think it's permissible to add
> new features to a CR without first going back to a last call that
> includes those new features.
XSD already has date/time types; sometimes an increase in
interoperability (here by specifying an additional mapping from a
lexical form, probbably) is worth while even at CR.

Preserving timezones would be harder, since currently XSD times are
historical (or extensionally defined), not intensional - there's no way
in XSD to represent "the third Tuesday of the month" for exampel, or
"8am local time, varying in UTC depending on the status of daylight
savings time" for example.

I think adding intensional time would be a significant change, and Mike
Kay's idea of a separate document makes sense there.

Adding a mapping from the "time" values to existing XSD types/values
might not be a big deal, which is what I was thinking of, although if
they're not stable I agree that it's not the time.

I was originally hoping that e.g. an RFC822 timestamp would be
supported, as that's a stable, well-documented and widely used format
for timestamps and seemed sensible for use in HTML (the ISO style is
obviously better for i18n but we already have that).

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Received on Tuesday, 22 November 2011 14:14:27 UTC