[whatwg] Microdata feedback

[Ian Hickson]

On Wed, 13 Feb 2013, Ed Summers wrote:
> 
> I am looking for some guidance about the use of multiple itemtypes in 
> microdata [1], specifically the phrase "defined to use the same 
> vocabulary" in:
> 
> """
> The item types must all be types defined in applicable specifications
> and must all be defined to use the same vocabulary.
> """
> 
> For example, does this mean that I can't say:
> 
> <div itemscope itemtype="http://acme.com/Foo http://zenith.com/Bar"> ... </div>

It depends on what http://acme.com/Foo and http://zenith.com/Bar are. If 
they use the same vocabulary, then you can do it. If they're separate 
vocabularies, then no.


> The reason I ask is that there is some desire over in the schema.org 
> community [2] to provide a mechanism for schema.org to be specialized. 
> For example, in the case of an audiobook:
> 
> <div itemscope itemtype="http://schema.org/Book
> http://www.productontology.org/id/Audiobook"> ... </div>
> 
> The idea being not to overload schema.org with more vocabulary, and to 
> let vocabularies grow a bit more organically.

If they're the same vocabulary -- that is, the properties on this .../Book 
vocabulary and this .../Audiobook vocabulary don't clash -- properties 
mean the same thing in both -- then it's fine.


> This schema.org group is currently thinking of using a one off property 
> additionalType that would be used like so:
> 
> <div itemscope itemtype="http://schema.org/Book">
>   <link itemprop="additionalType"
> href="http://www.productontology.org/id/Audiobook">
>   ...
> </div>
> 
> I personally find this to be kind of distasteful since it replicates the 
> mechanics that microdata's itemtype already offers.

It's essentially equivalent, yes.


> So, my question: is it the case that itemtype cannot reference types in 
> different vocabularies like the example above? If so, I'm curious to 
> know what the rationale was, and if perhaps it could be relaxed.

If they're different vocabularies (i.e. the same terms are used to mean 
different things), then you wouldn't know which was meant, so it would be 
ambiguous. There's an open bug about this topic with an open question:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=13527


On Thu, 14 Feb 2013, Ed Summers wrote:
> 
> In John's email [1] he proposed limiting multiple types to being from 
> the same origin domain, not the same vocabulary as is stated in the 
> Microdata spec. It sounds like an obvious question, but is there a 
> precise definition of what is meant by "same vocabulary"? Or is it just 
> a hand wavy way of talking about what humans understand when putting the 
> itemtype URLs in their browsers, reading, and understanding that they 
> are types that are part of some larger coherent whole?

"Vocabulary" means the set of properties that are defined. There's some 
non-normative text in the HTML spec that talks about this:

# The type gives the context for the properties, thus selecting a
# vocabulary: a property named "class" given for an item with the type
# "http://census.example/person" might refer to the economic class of
# an individual, while a property named "class" given for an item with
# the type "http://example.com/school/teacher" might refer to the
# classroom a teacher has been assigned. Several types can share a
# vocabulary. For example, the types
# "http://example.org/people/teacher" and
# "http://example.org/people/engineer" could be defined to use the
# same vocabulary (though maybe some properties would not be
# especially useful in both cases, e.g. maybe the
# "http://example.org/people/engineer" type might not typically be
# used with the "classroom" property). Multiple types defined to use
# the same vocabulary can be given for a single item by listing the
# URLs as a space-separated list in the attribute' value. An item
# cannot be given two types if they do not use the same vocabulary,
# however.


On Tue, 19 Feb 2013, Judson Lester wrote:
>
> There was an email from last year suggesting that the values of input 
> elements be derived from their value attributes - the purpose there 
> being to be able to control the form via the microdata interface.  I've 
> only been able to read it in the archives - the brief exchange was 
> between Igor Nikolev and Ian Hickson, who was curious about use cases.
> 
> Conversely, it would be useful to be able to use input elements to 
> contain item values, and at the moment, since their values would be 
> derived from their textContent, they're useless for that.  
> Specifically, it's often reasonable to present a representation as the 
> default values in a form and allow for updates simply by posting the 
> changed values.  It seems unwieldy to need to replicate that information 
> in e.g. data elements.
> 
> While it would be simple to treat the defaultValue as the item property 
> value for elements (and for radio inputs, let the representation mark 
> the selected input as the itemprop), it seems counter to the spirit of 
> the proposal.  The alternative would be to do something like excluding 
> unsuccessful input elements during the property crawl - which would 
> allow all such inputs to be marked as itemprop="name" and only the 
> selected one contribute to the itemscope's property list.
> 
> I think Igor had a point though - a consequence of making input elements 
> useful as itemprop elements would be that it ought to be possible to 
> assign values to inputs via HTMLElement.itemValue= and see those values 
> reflected in the form.  It seems like it wouldn't be the best means to 
> manipulate form data though, since e.g. radio inputs would behave 
> strangely under the current interface (yes_radio.itemValue="no" should 
> probably change the value of the button, not which button is selected).
> 
> I find the use case of a form to present key/value data compelling, and 
> being able to apply microdata vocabularies to same strikes me as 
> particularly useful.

There's been some discussion of this on this bug:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=17933

I haven't yet been able to understand what problem this would really 
solve, though. Could you elaborate on what you are doing that would 
benefit from doing this?


On Thu, 30 May 2013, Michael[tm] Smith wrote:
> Jirka Kosek <jirka at kosek.cz>, 2013-05-14 17:22 +0200:
> > 
> > are there any plans to change Microdata API? From the following 
> > conversation between Chromium developers it's not clear to me whether 
> > they consider API itself bad or only their implementation.
> > 
> > https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/b54nW_mGSVU
> > 
> > Any insight welcomed.
> 
> Not claiming to speak for anybody on the Chrome/Blink team but as far as 
> that conversation among the Chromium developers, looking at it from the 
> outside at least, my read is that they consider the current API spec to 
> be bad -- not just their implementation.
> 
> That said, it doesn't seem like anybody in the discussion other than 
> Ojan mentioned anything bad in particular about the API spec. Ojan's 
> comment:
> 
>   "I have one concern with the feature as specced is that getItems and the
>   various Collection returning properties/methods all return live
>   NodeLists/Collections. [...] Live NodeLists/Collections impose a large
>   cost on the rest of the codebase and fundamentally make regular DOM
>   operations slower.
> 
> Then there's a general comment from Alex:
> 
>   "The current micro data API is...poor. I think we should write it off and
>   try again. No opinions in what that means for our impl in the meantime,
>   though (other than it shouldn't ship, of course). I'm happy to put work
>   into a better API if someone will collaborate on impl."
> 
> So anyway, it looks like the gist from the overall discussion is: 
> They've completely removed the Microdata API implementation from Blink, 
> and unless Alex or somebody else writes up an alternative API proposal 
> they can be happier with, it seems unlikely they're going to be 
> re-implementing anything based on the current Microdata API spec.

On Wed, 29 May 2013, Ojan Vafai wrote:
> 
> This concern could be addressed without much of a change to the current 
> API by returning static NodeLists and/or Collections. Hixie, consider 
> this feedback on the API. :) We're very unlikely to implement any new 
> APIs that return live NodeLists/Collections.

There's are actually cases where live NodeLists can be faster (e.g. 
because they can be lazily evaluated), so it's not immediately obvious 
which is better.

Since this has been implemented in Firefox already, I haven't changed the 
spec: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2431


> Whether addressing that would be enough that we'd be want to ship 
> Microdata is unclear to me.

Yeah, the real question is whether the underlying use cases are compelling 
enough for more browser vendors to care.


On Thu, 30 May 2013, Karl Dubost wrote:
> 
> In the process, if it ever happens, I would love to see something more 
> or less common in between RDFaLite, data-* and microdata. When I 
> explored different ways of expressing the same information, the JS code 
> to access the data is quite different and makes it not very user 
> friendly in the end.

RDFa, microdata, and data-* have quite different data models. I don't 
think it would make sense to have one API for all three; at best two of 
them would have to be shoe-horned into something that didn't fit their 
model. (Also, it's not clear what the use case would be.)

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