When someone uses a type like <http://schema.org/Person/Engineer>, it
is impossible to use the microdata DOM API as intended --
document.getItems("http://schema.org/Person") would not return those
items. The root issue is of course that microdata types are opaque
URIs, while schema.org is encoding a microsyntax for extensibility in
them that needs special parsing.
(It is true that document.getItems("http://schema.org/CreativeWork")
will also not return any <http://schema.org/Movie>s and that this is
going to be a bit of a pain, but at least in this case there is a
fixed set of types that one could check, whereas the recommended
extensibility mechanism is simply unbounded.)
Are the sponsors willing to reconsider the approach to extensibility
to work better with the URIs-as-opaque-identifiers in general and with
the DOM API in particular?
[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata-dom-api
--
Philip Jägenstedt
<div itemscope itemtype="http://schema.org/Person http://example.org/Engineer">
This way the DOM API can continue to work and it's actually possible
to document in http://example.org/Engineer what it means, which is of
course not possible if everybody is extending schema.org URLs. (IMO
opinion it's also a plus that it's more verbose, to somewhat
discourage people from making extensions unless they actually need
to.)
Was this approach considered and discarded? If the spec allowed it,
would that make any difference?
Philip
--
Philip Jägenstedt
I'm not concerned about exposing type hierarchies in general, it's
allowing extensions by string concatenation that seems a bit odd.
Although more verbose, I think that allowing multiple item types is
less awful:
<div itemscope itemtype="http://schema.org/Person http://example.org/Engineer">
This way the DOM API can continue to work and it's actually possible
to document in http://example.org/Engineer what it means, which is of
course not possible if everybody is extending schema.org URLs. (IMO
opinion it's also a plus that it's more verbose, to somewhat
discourage people from making extensions unless they actually need
to.)
Was this approach considered and discarded? If the spec allowed it,
would that make any difference?
itemtype doesn't do any scoping, it's the itemscope attribute alone
which does this. (itemtype is optional, but of course required in the
schema.org vocabulary.)
Of course, allowing multiple types means that itemType would have to
be a DOMSettableTokenList (like classList), which is a slight
uglification.
It's far from obvious what the best solution here would be, but I do
hope that the DOM API is taken seriously, even though it won't be used
by search engines.
--
Philip Jägenstedt