This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This feedback is filed as a personal comment and is not intended to be any sort of official feedback from any standards working group. Microdata currently does not support multiple types per item. For example, when specifying an object, one cannot do the following: <div itemscope itemtype="http://schema.org/FurnitureStore http://schema.org/GardenStore http://schema.org/HardwareStore"> <span property="name">Home Depot</span> sells a variety of things. </div> It is restrictive to categorize some items under a fixed heading. RDFa allows you to do the following: <div vocab="http://schema.org/ typeof="FurnitureStore GardenStore HardwareStore"> <span property="name">Home Depot</span> sells a variety of things. </div> I understand the technical reason for this restriction, but that technical restriction results in the over-simplification of some types of data found in real-world scenarios. I suggest that Microdata add support for multiple item types to remove this restriction.
This was discussed in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032243.html with no real conclusion.
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: Rejected Change Description: no spec change Rationale: The conclusion was in: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032260.html This is unnecessary, because if you want to indicate that an element has multiple categories, you just need to define a property whose value is those categories. The itemtype="" attribute doesn't specify an item's categories, it gives the item's vocabulary (its type, in programming terms). If you're trying to use multiple vocabularies with one item, this isn't possible because there'd be no way to disambiguate terms without vocabulary knowledge. Don't do that.
mass-move component to LC1
Then change @itemtype to @itemvocab to make it more clear that this is what is happening.
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: Rejected Change Description: no spec change Rationale: The term "type" is being used in a way that is consistent with its meaning in the industry. It might not be the meaning used in the Semantic Web space, but that isn't the target audience here.
Limiting an item's type to just one thing and making properties like 'name' specific to that type is unnecessarily limiting. It is quite often that something in the real world can be multiple types of things - a car can be a vehicle and a shelter. A person can be a mother and a sibling. I don't agree that objects that are singly-typed should be the way forward for a semantic expression language in HTML5. That said, I don't think that the editor is going to change his mind on this issue. The reasoning behind the requirement of multiple types per item has been made clear, the Editor is still not convinced, I am not happy with the resulting limitation it places on content authors. My concern has not been addressed, but I'm dropping the issue.