[whatwg] multiple itemtypes in microdata?

[Ian Hickson]

On Tue, 28 Jun 2011, Philip Jägenstedt wrote:
> On Mon, 27 Jun 2011 07:53:53 +0200, John Giannandrea <jgiann at google.com>
> wrote:
> > 
> > In the user feedback from the schema.org proposal, which uses 
> > microdata as its syntax, we have seen several use cases that would 
> > seem to require multiple itemtypes per itemscope.
> > 
> > Currently the microdata spec only allows one itemtype which defines 
> > the meaning of the vocabulary for subsequent itemprops.
> > 
> > Allowing an arbitrary list of itemtypes would not be desirable because 
> > then a user agent would have to have knowledge of the type 
> > vocabularies in order to parse the page.
> 
> Nothing needs to be known about the vocabulary in order to handle 
> itemtype currently, at least if by "user agent" you mean browsers and 
> the DOM API. In other words, allowing multiple types wouldn't be a 
> problem here.

That depends how multiple types are done. If all the non-URL properties 
are assumed to be those defined by the first type, then it's fine. But if 
you want to be able to use terms from either vocabulary, you'd need 
vocabulary knowledge to be able to preprocess the data, which would be 
counter to microdata's design goals.

(For example, suppose you have types A and B and A defined property 'foo'. 
You have:

  <div itemscope itemtype="A B">
    <span itemprop="foo">...</span>
  </div>

  <div itemscope itemtype="B A">
    <span itemprop="foo">...</span>
  </div>

If type "B" later has a property "foo" defined as well, the meaning of 
existing pages changes, as does the necessary processing for generic 
processors that just want to tag each item with unambiguous properties 
(e.g. the vocabulary-agnostic Microdata to RDFa conversion algorithm).


> > We suggest that itemtype be changed to allow multiple space separated 
> > types (just like itemprop), but only if the origin domain of the types 
> > is the same.  This would allow a vocabulary provider to allow multiple 
> > types and to take responsibility for what the property vocabulary 
> > definition is in the context of more than one type.
> 
> The itemtype is supposed to be an opaque string, so it seems quite odd 
> to impose restrictions that require parsing the string to get the domain 
> name. In the case of schema.org, wouldn't it be quite helpful if people 
> extended it somewhere *other* than schema.org, so that it would be 
> possible to follow the itemtype URL and perhaps find some documentation 
> of the type? (Not necessary anything fancy, see e.g. 
> http://n.whatwg.org/work)

The solution John proposed would indeed not handle cross-origin 
extensions, which could be problematic.

Another solution would be to not use types in this way, but to have a 
property that gives the kinds of item, so instead of:

   <div itemscope itemtype="http://example.com/A http://example.com/B">
     ...
   </div>

   <div itemscope itemtype="http://example.com/">
     <meta itemprop="kind" content="A B">
     ...
   </div>

John, can you elaborate on why this wouldn't solve the problem for 
schema.org? It seems like it would be equivalent to the origin-driven-type 
solution, but has the advantage of not complicating the model at all.

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