DOM API compatibility

[Philip Jägenstedt]

The approach taken to extensibility in
http://schema.org/docs/extension.html is fairly worrying. Jeni
Tennison wrote a bit about it in
<http://jenitennison.com/blog/node/156>, and there's a related issue
with the DOM API [1] I wanted to bring up.

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

[Guha]

While we are certainly open, I don't think DOM API access to the type hierarchy is one of our goals.

 if we are going to try to get teh DOM API work with the hierarchy, the solution should solve the problem of not retrieving Movies when querying for CreativeWork. I don't see a simple way to do this, at least not without using some library that goes and imports the heirarchy from some external source.

guha

[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?

Philip

--
Philip Jägenstedt

[Stéphane Corlosquet]

On Mon, Jun 20, 2011 at 9:15 AM, Philip Jägenstedt <phi...@foolip.org> wrote:

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?

Slightly off topic, but one needs to bear in mind that if this was allowed in the spec, each property could not benefit from the automatic scoping of the itemtype vocabulary, so most likely each property would have to be full URLs (e.g. http://schema.org/name), unless there was another attribute (itemvocab) which was used to set the default vocabulary of the item.

Steph.

[Philip Jägenstedt]

On Mon, Jun 20, 2011 at 16:34, Stéphane Corlosquet
<scorl...@gmail.com> wrote:
>
>
> On Mon, Jun 20, 2011 at 9:15 AM, Philip Jägenstedt <phi...@foolip.org>
> wrote:
>>
>> 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?
>
> Slightly off topic, but one needs to bear in mind that if this was allowed
> in the spec, each property could not benefit from the automatic scoping of
> the itemtype vocabulary, so most likely each property would have to be full
> URLs (e.g. http://schema.org/name), unless there was another attribute
> (itemvocab) which was used to set the default vocabulary of the item.

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