RE: [Bug12318] <time> vs. <data> semantic tags for machine-readable content

Cameron,

It's great to hear that you're willing to work toward an extension spec! Recently, the HTML working group has put together some rough guidelines for building such a spec; I'd encourage you to get one together for us all to review.

Here's where we're tracking existing extensions specs:
http://www.w3.org/html/wg/wiki/ExtensionSpecifications

Here's the "how-to" guide and expectations:
http://www.w3.org/html/wg/wiki/ExtensionHowTo

I'll resolve Giorgio's bug as Needs Info as is our new technique for handling these types of larger features.

Thanks,
-travis

From: Cameron Jones [mailto:cmhjones@gmail.com]
Sent: Saturday, February 2, 2013 8:06 AM
To: Travis Leithead
Cc: public-html@w3.org; philipj@opera.com; giorgio.liscio@email.it
Subject: Re: [Bug12318] <time> vs. <data> semantic tags for machine-readable content

On Fri, Feb 1, 2013 at 10:56 PM, Travis Leithead <travis.leithead@microsoft.com<mailto:travis.leithead@microsoft.com>> wrote:
Bug 12318 [1] requests a new semantic element: <measure> to be able to mark up additional measurements for machine readable processing. This is very similar in principle to the <time> element, but somewhat more generic (for measurements). It was proposed that either the <time> element be extended to support more generic scenarios, or that a new element (like <measure>) be created but for the specific purposes of marking up machine-readable content.

Since this bug was filed, a proposal exists [2] for a new <data> element which looks like it meets the use case described in this bug.

Is <data> a useful new tag?

Is <time> still useful? Should it be enhanced to allow for additional scenarios?

If <data> seems useful, then we could resolve this bug by either bringing <data> directly into HTML5.1, or creating an extension spec for <data> (or something like it). Otherwise, we might as well resolve this bug won't fix.

Thoughts?

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=12318
[2] http://www.whatwg.org/specs/web-apps/current-work/#the-data-element


Hi Travis,

I've done some work into this area through the time\data debate which was logged under issues 183[1] and 184[2]. If you have a look at my proposals from each[3][4] you'll see how far i got in trying to plot a direction for this expanding area of functionality and use cases. I haven't done any further work on it since as the emphasis is on HTML5 and, especially with plan2014, the amount of work required wouldn't line up with that development timeframe.

That being said, i believe that for HTML5.1 this could be one of the most significant areas of new functionality with the express interest in developing greater automation and personalization within the browser for unit conversions and preferences, and also aiding document processing.

There is a natural synergy with data-markup technology (RDFa, MIcrodata) which could be argued as being the space for data typing, however the space for times, units, measurements is more quintessential and more naturally aligned to programmatic datatypes, hence the recommendation that this could form a "HTML Type System" with direct integration with the HTML input types and Javascript data structures\functions.

The primary open question from which all further work would be defined is that of a single general-purpose <data> element, or multiple domain-specific elements for each refined data-kind. The implementation of <time> falls under the latter and, in my analysis, is a duplet data structure shared between the element and value attribute, with distinction encoded within the value syntax. The former approach of <data> is a tuplet of element, type and value, with global distinction defined within a single type discriminator. The hypothesis which i put forward is that a tuplet-based structure is more capable of distinct and flexible data encoding. If it's good for RDF, Microdata and DNA Codons, it should be suitable for a future-proof HTML Type System.

Look forward to more discussions and keen to work towards an extension spec for HTML 5.1

Thanks,
Cameron Jones

[1] http://www.w3.org/html/wg/tracker/issues/183
[2] http://www.w3.org/html/wg/tracker/issues/184
[3] http://www.w3.org/wiki/User:Cjones/ISSUE-183
[4] http://www.w3.org/wiki/User:Cjones/ISSUE-184