- From: <bugzilla@jessica.w3.org>
- Date: Fri, 28 Oct 2011 15:19:15 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14586 --- Comment #1 from Philip Jägenstedt <philipj@opera.com> 2011-10-28 15:19:14 UTC --- itemType is a plain DOMSettableTokenList, so any tokens are visible, even those that are not absolute URLs. The definition of getItems seems contradictory, talking about "top-level microdata items whose _types_ include all the types specified in the method's argument, having obtained the types by splitting the string on spaces." _types_ is xref'd to [1] which talks about "the absolute URLs obtained by splitting the element's itemtype attribute's value on spaces". Are the types obtained by simply "splitting the string on spaces" or are they restricted to absolute URLs? The note makes it clear that the latter is intended, so "having obtained the types by splitting the string on spaces" must be left-overs from the last spec change. The JSON export algorithm also refers to [1], such that only absolute URLs would be included. It is inconsistent to expose all tokens in itemType but only valid ones via getItems() and JSON. Actually checking that the token is an absolute URL is a bit annoying when implementing (I'm trying to update Live Microdata), so I would prefer that both getItems and the JSON export just treat the tokens as opaque strings and not care that they are URLs. Finally, by having the API filter the types, it'll be more painful if we ever want to allow non-URL item types, such as private-use itemtype="foo" or reverse DNS itemtype="com.example.Thing". [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#item-types -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 28 October 2011 15:19:23 UTC