[Bug 12318] feature request: a more semantic tag for non-intl-measures?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=12318

--- Comment #10 from Travis Leithead [MSFT] <travil@microsoft.com> ---
(In reply to comment #9)
> 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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 5 March 2013 00:17:26 UTC