This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Logging this bug at the request of Philip Jägenstedt: When you use the same @itemid on the page, and you retrieve data using the Microdata DOM API, is the expected behavior that: 1) All properties for the same @itemid are merged with two separate items on the page. 2) All properties and types for the same @itemid are merged. 3) What happens when somebody does a getItems() and uses one of the itemtypes - are all properties returned? With RDFa and RDF in general, all things w/ the same "@itemid" (aka: "@about") would be merged into a single object with multiple types when retrieved via the RDFa API. This is, in fact, what happens with RDF output for Philip's Microdata parser. However, the JSON output creates two objects with non-overlapping properties. What is the proper behavior?
What I'm doing in MicrodataJS is per spec, see http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#json The only way that itemid feeds into the JSON export is """If the item has an global identifier, add an entry to result called "id" whose value is the global identifier of item.""" IMO, this is just fine as it is.
This doesn't seem reasonable. @itemid identifies a global subject for a set of triples. You can specify multiple different sets of triples for the same global object, using different vocabularies. It doesn't seem useful or reasonable to merge these into a single Microdata item. For example, I may mark up, on the same page, a review of a book and purchasing information about the book, using two different vocabs but using @itemid to specify they're both about the same book. When reading out the review item I wouldn't want the data to be polluted with purchasing information, and vice versa.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I don't understand. Could you elaborate? What's the problem here? Note that the semantic of itemid="" is entirely up to the vocabulary. We can't assume any particular processing for multiple items with the same itemid="".
mass-move component to LC1