Re: <time> values in HTML5

On Nov 18, 2011, at 5:05 PM, Jeni Tennison wrote:

> Hi,
> 
> The all new <time> element has been specced out in the WHATWG version of the HTML(5) spec at:
> 
>  http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element
> 
> (This isn't reflected in the W3C Editors Draft as yet but I guess it will be at some point.)
> 
> As specced, it (a) accepts a bunch of syntaxes that aren't in the lexical space of any XML Schema datatype and (b) accepts some values that aren't in the value space of any XML Schema datatype, namely timezones and weeks.
> 
> Looking at this from the perspective of extracting data into either RDF or XML systems, syntax variations aren't a particular issue, as values can be normalised to the standard lexical space for the relevant XSD type as they're extracted. However, there's simply no appropriate datatype to use when mapping the values that aren't covered by XML Schema.
> 
> I see XML Schema 1.1 [1] is at Candidate Recommendation stage. Is it too late to slip in a xs:timezone and a xs:gYearWeek? Or should HTML+RDFa 1.1 do like the XPath Data Model did [2] and add definitions for these types so it can use them? Or should the types be created in a completely different namespace? Or should values of these types go typeless into any RDF or XML generated from HTML5?
> 
> Any thoughts?

Thank you for the pointer and the suggestion.

Adding a new built-in type is likely to be difficult at this stage, as it would
be hard to argue that it was not a substantive change to the spec, and
in the past there have been explicit objections to precisely those features 
in earlier versions of XSD that would have made it possible to accept
new syntaxes for existing value spaces and to define new value spaces
consisting of arbitrary spans of time (as would be needed to relate the
values of strings like "2011-W46" to those of date and related types).
(No, to this day I don't understand why the internationalization WG objected
to those features, or why they thought them to be i18n-related.  But they
did, and the director sustained their objection, so the date-time types of
XSD have a somewhat less coherent design than they originally possessed.
It's too late to change that now, I think.)

On the other hand, one of the most important changes in XSD 1.1 is
the rule that conforming implementations may support additional primitive
types.  So one possibility would be for interested parties to specify a
type corresponding to the possible values of the 'time' element, which
processors could support if they chose.

For processors which don't support the extension type, it would be
possible to define a union type which accepted all and only the strings
valid in the time element, and which mapped those strings to appropriate
items in the appropriate XSD value spaces where possible.  Strings
that aren't in a built-in lexical space would end up mapping to strings,
which is sub-optimal in some environments and irrelevant in others.
It would be possible, I think (but I have not thought about that much) to
define functions in XSLT 2.0 or XQuery to map those strings to appropriate
typed values.

It would be an interesting exercise to specify both an extension type
with its own value space and lexical mapping, and a type usable in 
processors which don't support the extension type.   I think the XML
Schema WG might be interested in collaborating on a document with
such a specification; if the WG isn't interested as a group, I expect that
some individuals in the WG may be interested.  From the XML Schema
WG's point of view, such a document would probably be interesting and
worth working on even if some of those interested in HTML5 and RDF
were to decide they don't care to use it.


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Received on Friday, 2 December 2011 16:12:35 UTC