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> 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