[whatwg] Annotating structured data that HTML has no semantics for

[Ian Hickson]

On Tue, 9 Jun 2009, Jonas Sicking wrote:
> >>
> >> Some of the improvement suggestions that I have heard that sounds 
> >> interesting, though possibly for the next version of microdata.
> >>
> >> * Support for specifying a machine-readable value, such as for dates, 
> >> colors, numbers, etc.
> >
> > I expect we will add support for these based on demand, the same way 
> > we added <time> in the first place.
> 
> Using dedicated elements for each data type seems like it will 
> eventually bloat the language.

Only if people don't show restraint in extending the language.


> For example what use would a <color> element or a <number> element do?

It would allow conformance checkers to do type checking for the most 
commonly used types, and might allow (for number, anyway) localised 
formatting.


> If instead mashine readable values could be added using a generic 
> method, such as a 'itemvalue' or 'propvalue' attribute, each microdata 
> format can define how to interpret the values, be they numbers, dates, 
> body parts, or chemical formulas.

You can do that now with <meta itemprop=... content=...>.


> >> I even wonder it would allow replacing the <time> element with a 
> >> standardized microformat, such as:
> >>
> >> Christmas is going down on <span item="w3c.time" 
> >> itemvalue="12-25-2009">The 25th day of December<span>!
> >
> > I don't really understand how that would be better than dedicated 
> > elements.
> 
> The idea would be to reduce the size of the language. I.e. if a feature 
> isn't heavily used, it might be better expressed as a microdata format. 

Well, you can do it today as:

   Christmas is going down on <meta itemprop="w3c.time" 
   content="12-25-2009">The 25th day of December!

...which (assuming that in your example you meant "itemprop" and not 
"item", and assuming that you didn't mean the contents of the <span> to 
have any effect on the microdata processing model) would result in exactly 
the same name/value pair being generated into the relevant item.

On the other hand, if you really meant item="", which I guess you might 
have meant... you could do that today as:

   Christmas is going down on <span item="w3c.time"><meta itemprop="value"
   content="12-25-2009">The 25th day of December</span>!

...or some such (it doesn't matter what the textual contents of the <span> 
are in this example). However, this is going to result in much more 
painful structures, and you'd still need to link the item with a parent 
item (assuming there is one), as in:

   <div item="com.example.somethingorother">
    Christmas is going down on <span itemprop="com.example.startdate" 
    item="w3c.time"><meta itemprop="value" content="12-25-2009">The 25th 
    day of December</span>!
   </div>

...which is really getting complicated compared to just:

   <div item="com.example.somethingorother">
    Christmas is going down on <meta itemprop="w3c.time" 
    content="12-25-2009">The 25th day of December!
   </div>

...or (preferred today):

   <div item="com.example.somethingorother">
    Christmas is going down on <time itemprop="w3c.time" 
    datetime="12-25-2009">The 25th day of December</time>!
   </div>


> For example, why didn't you add elements for bibtex or vCard, but 
> instead used microdata?

New elements didn't really fit the use cases as well.


> Another reason is as a test of the microdata feature itself. Microdata 
> is a sort of extension mechanism to HTML 5. In software development, it 
> is common to test your extension system by developing parts of the 
> product using the extension system. This way you can both keep the core 
> code small, and you get a good test bed for your extension system.

Indeed.


> You have already done this with the "predefined vocabularies"

Right.


> and apparently the lack of ability to define a mashine readable value 
> separate from the human readable one was not a problem. However it would 
> seem that the same does not hold true for <time>.

Right, that's why I adapted <time> into the microdata model.


> >> * Support for tabular data.
> >
> > This would be nice if we can find a way to do it that doesn't put 
> > undue burdens on simple implementations. (e.g. I would imagine that 
> > while a microdata implementation today can be a few hundred lines 
> > total, adding support for the table model could easily double that.)
>
> Quite possibly.
> 
> In both these cases I'm perfectly happy to wait with adding more 
> features to microdata for now and see if what we have is successful, 
> before we start over engineering it to cover every imaginable case.

Agreed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'