- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 28 Jun 2011 15:24:01 +0200
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. > 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) In short, I think that simply allowing multiple types would be a workable solution here, without any specific restrictions. The only change to the DOM API would be making the itemType IDL attribute a DOMSettableTokenList, just like itemRef and itemProp. -- Philip J?genstedt Core Developer Opera Software
Received on Tuesday, 28 June 2011 06:24:01 UTC