Re: ISSUE-76: Need feedback on splitting Microdata into separate specification

On Mon, 2009-12-07 at 18:23 +0000, Ian Hickson wrote:
> It's actually even worse than those two, because the microdata
> processing model makes certain assumptions about the vocabulary. For
> SVG to reuse itemscope=""/itemprop=""/etc, the processing model would
> have to be rewritten to define how it works in SVG, and SVG would have
> to be extended to provide parallels for <time itemprop datetime>,
> <meta itemprop content>, <link itemprop href>, etc. 

I've been playing around with trying to implement Microdata and I don't
think this is as big an issue as you're making out. Certainly it would
be something the editor of a split-out Microdata spec would have to
consider, if supporting non-HTML host languages was an aim, but it's not
a big difficulty.

It would be quite easy to say, for the value of a property element:

 - if the element has an itemscope attribute, use the item;
 - otherwise, if it has a content attribute, use that;
 - otherwise, if it has an href attribute, use that;
 - otherwise, if it has a src attribute, use that;
 - otherwise, if it has a datetime attribute, use that;
 - otherwise, use the text content.

That's not *entirely* consistent with the current draft, but it is
mostly in keeping with the spirit of it. For most conformant content, it
will produce the same end result (exceptions being <object itemprop>,
<ins itemprop datetime> and <del itemprop datetime>

SVG 1.2 Tiny already has a content attribute, usable on any SVG element,
and an href element too (albeit in the XLink namespace).

For host markup languages which don't already have these attributes, a
host-neutral Microdata spec could provide them in addition to providing
the item* attributes.

This issue is certainly not insurmountable.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Monday, 7 December 2009 22:00:42 UTC