W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

[Bug 13240] Consider replacing <time> with <data>

From: <bugzilla@jessica.w3.org>
Date: Thu, 11 Aug 2011 12:58:09 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QrUpt-0001ce-Hf@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240

--- Comment #30 from Cameron Jones <cmhjones@gmail.com> 2011-08-11 12:58:07 UTC ---
(In reply to comment #25)
> I'm definitely leaning towards doing this. The alternative seems to be to have
> a whole slew of elements for this kind of thing:
> 
>    <time datetime="2010-10-10">
>    <number value=10>
>    <scalar value=10 unit=kg>
>    <duration value="1h10m2.2s">
>    <timerange start="2010-01-01" end="2010-02-02">
>    <enum value="spring">
> 
> ...all of which pretty much do exactly the same thing: nothing.

as a non-exhaustive set of examples they revel the implications of including
such fine-grained tags. if these elements are included the same reasoning would
be unable to exclude the entire raft of other elementary data types.

any specification of these as distinct elements would have to content with a
large overlap in common features, yet diverging implementation. this leads to
problems such a requiring a <timerange> element to represent ranges in time,
yet which is unable to represent generic ranges, of numbers, scalars, even
durations.

i believe a more generic solution, such as <data> is required in order to have
a solution which is capable of representing every value without requiring every
data type to be discovered, specified and implemented.

in short, i think <time> and its relatives represent a non-scalable solution
for a specification and does not leverage the ability for authoring creativity
and innovation to drive the web forward.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 11 August 2011 12:58:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:16 UTC