W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

[Bug 14586] Microdata: inconsistency between itemType, getItems and JSON regarding absolute URLs

From: <bugzilla@jessica.w3.org>
Date: Fri, 28 Oct 2011 15:19:15 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RJoDD-00047l-CX@jessica.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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:06 UTC