[Bug 8107] I dont think that itemid should be prohibited if there is no itemtype. Several of the use cases would work fine with an id but no type

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8107


Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #11 from Ian 'Hixie' Hickson <ian@hixie.ch>  2009-12-13 15:52:37 ---
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: 

This seems to be an abuse of the URL concept. As I said in comment 3, I
understand that one can use URLs to identify something other than what the URL
strictly identifies (as defined by the scheme registration and other applicable
specifications), but to do so you need to have a specification that says how
you are going to interpret the URL. In the absence of such a specification, a
URL has no meaning beyond just referencing a Web page (or mailbox, or whatever
kind of resource the scheme references). I think we would be encouraging very
dubious behaviour if we were to encourage people to use itemid="" to identify
non-Web-page concepts or resources without previously defining what they are.

To put this in more concrete terms, consider what happens if two independent
Web pages by two different authors both write:

   <div itemscope itemid="http://google.com/">

...in their page. Are they referencing the same thing? One has:

   <div itemscope itemid="http://google.com/">
     <span itemprop="background-color">#FFFFFF</span>
     <span itemprop="price">$0</span>
   </div>

...and the other has:

   <div itemscope itemid="http://google.com/">
     <span itemprop="employee-count">12345</span>
     <span itemprop="price">$500</span>
   </div>

Now are they referencing the same thing? Do we want to encourage search engines
to treat them as referencing the same thing?

The whole point of name-value pairs that don't have an itemtype="" is that you
can't know what the author meant, because they're using their own proprietary
vocabulary. We don't want to encourage any aggregation of that data by third
parties. Data should only be aggregated (or used in any way) by third parties
like search engines when the data has a declared vocabulary, or when the
itemprop="" is a URL. You are welcome to define a URL itemprop="" value that is
defined to give a global identifier, assuming you define how that global
identifier is to be interpreted, so that e.g. one could have:

   <div itemscope>
     <link itemprop="http://vocabs.example/gid/webpage"
href="http://google/com/">
     <span itemprop="background-color">#FFFFFF</span>
     <span itemprop="price">$0</span>
   </div>

   <div itemscope>
     <link itemprop="http://vocabs.example/gid/public-company"
href="http://google/com/">
     <span itemprop="employee-count">12345</span>
     <span itemprop="price">$500</span>
   </div>

...(though you still couldn't use the "background-color", "price", and
"employee-count" values, since they aren't globally defined), but I think that
reusing itemid="" for this purpose without an itemtype="" would lead to
mistakes, and thus we should continue to discourage it.


-- 
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 Sunday, 13 December 2009 15:52:38 UTC