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

On Mon, 7 Dec 2009, Toby Inkster wrote:
> 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.

I agree that we could design a language that is compatible with other 
vocabularies and is not much different from microdata, but I don't think 
we could take the existing microdata processing model unchanged. I also 
think that porting microdata to be a vocabulary-agnostic feature would be 
a net negative, as many of microdata's benefits are drawn directly from 
its tight integration with HTML, e.g. the close coupling with <time>.


> 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 wouldn't be an ideal model. It would lead, for instance, to the 
<base> element's href="" attribute being a way to set an item property, 
which I think would be undesireable (that's not really a resource URL, 
it's a base URL). It would mean <object>'s semantics would be less 
intuitive, and it would lead to <ins> having the weird effect of setting 
the date rather than the contents. It would also constrain other 
languages, e.g. in SVG you might prefer itemprop="" to work with XLink 
rather than href="" and src="".

I think it is much better to design specific features that work well in 
their host language than generic features that work the same everywhere 
but work well nowhere.


> This issue is certainly not insurmountable.

Indeed not. However, I don't think it's trivial, and it's unclear that 
it's desireable.


On Mon, 7 Dec 2009, Martin McEvoy wrote:
> > 
> > [...] 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,
> 
> Hmm I don't know if that is an accurate assertion...
> 
> .."The semantics of the RDFa attributes are the same as for XHTML"...
> 
> http://www.w3.org/QA/2008/12/rdfa_and_svg_tiny_and_the_rdfa.html
> 
> There are differences but not much ;)

RDFa is language-neutral by design. Microdata is language-specific by 
design. It's a pretty major difference (and is the source of some of 
microdata's benefits over RDFa), and it is highly relevant here. One could 
not simply say "the semantics of microdata attributes are the same as for 
XHTML", that just wouldn't work.

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

Received on Tuesday, 8 December 2009 08:51:13 UTC