W3C home > Mailing lists > Public > www-html@w3.org > September 2006

Re: Number, Date, Time, Quantity

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 6 Sep 2006 20:19:41 +0100
Message-ID: <640dd5060609061219y479896bcq9098d283dab41164@mail.gmail.com>
To: www-html@w3.org

Hi Christoph,

> *Steven Pemberton*, 2006-08-30:
> > We have often had such requests for datatype elements, and one of
> > the questions was always "where do you stop?".
> I don't know, but it seems the HTML WG stopped too early and headed
> into another direction.

You've illustrated the whole point...you think it's too early today,
and we should have at least continued until we had incorporated dates
and times. Then in a years time when we stopped, someone else would
say that's too early, and we should have at least included weights and
measures...or musical symbols...or chemical symbols.

Our approach was therefore to provide a generic mechanism for
datatyping, and then the job is done.

I don't see this:

> >       <span datatype="xsd:date" content="2006-08-31">tomorrow</span>

being difficult, when compared to this:

>         <t datetime="2006-08-31">tomorrow</t>

But note anyway that the RDFa mechanism used in XHTML 2 is actually
more flexible than is immediately obvious. For example, it can be used
for situations like this:

  The <span content="Tony Blair">Prime Minister</span> will today travel to...

  The <span content="Winston Churchill">Prime Minister</span> today said ...

as well as:

  <span datatype="xsd:date">2006-09-06</span>

And of course, the @datetime approach has to hard code what the format
for a datetime is,  which is very prescriptive. The RDFa approach
provides a mechanism that can be used on sites dealing with anything
from astronomy to sports fixtures to shopping-carts to photography,
each area of interest having its own preference for what the format
for a 'date/time' should be.

By the way, I don't really count this as a viable solution:

>         <abbr class="dtstart" title="2006-08-31">tomorrow</abbr>

It overloads the semantics of @title, makes use of @class in too
specific a way, and adds a layer of interpretation of attributes that
depends on the values in other attributes, which is not generic. (And
as you can see at the microformats site, is a maintenance nightmare.)

I can see why it was done, but when planning for a proper solution the
only real choices are between two generic attributes that contain type
and value, or lots and lots of single attributes that are named for
each type, have the value as their content, and hard-code their



Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
Received on Wednesday, 6 September 2006 19:20:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:14 UTC