This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Problem: The language of the spec around allowed rel values does not match the categorizations for allowed rel values in microformats wiki, so it's not at all clear what rel values listed on that page are meant to be allowed and which aren't. But to solve that problem, I don't think we should bother trying to match the language on that wiki closely. I suggest instead that the spec just state, "Any rel value listed on the Microformats wiki existing-rel-values page must be accepted unless that page explicitly states it must not be used." Then, it's up to the maintainers of the page to make it clear there which values listed there must not be used or should not be used. Here are a few more specific details about the differences: Regarding names of link types in rel values, the spec currently states 'values defined in this specification or marked as "proposed" or "ratified" must be accepted...", where 'marked as "proposed" or "ratified"' means marked as such on the microformats "existing rel values" page. http://microformats.org/wiki/existing-rel-values http://dev.w3.org/html5/spec/links.html#other-link-types The spec also says, 'Types defined as extensions in the Microformats wiki existing-rel-values page with the status "proposed" or "ratified" may be used with the rel attribute...". However: 1. the microformats "existing rel values" page does not use the word "ratified" at all. It instead has a "formats" category, and says the values in that category are "recommended for general use" 2. the microformats "existing rel values" page does not use the word "proposed". Instead, it has a "proposals" category -- which is close -- but in addition to that, it also has other categories for not-yet-"formats"-level (not yet recommended) values; those include "brainstorming", "more brainstorming" (which links to further pages with more rel names), "POSH usage", "WCLR", "non HTML rel values", and "unspecified". For the "proposals" category, it states "You may use these values" and for the "brainstorming" category, it states, "consider trying out these values", but for none of the others does it say anything like "you must not use these values yet", so it would seem that as far as document conformance goes, all of them are essentially "proposed" and so should be valid (as far as the spirit of the law in the spec goes). Finally, the spec states, 'values marked as "discontinued" or not listed in either this specification or on the aforementioned page must be rejected as invalid'. But the wiki page does not have anything marked as 'discontinued'. It instead has "dropped" ("In general, you should not use any dropped values") and "rejected" ("Authors must not use rejected rel values.") Anyway, given all that, we can simplify things in the spec by just replacing the current language with a one-sentence, "Any rel value listed on the Microformats wiki existing-rel-values page must be accepted unless that page explicitly states it must not be used or should not be used." As far as the "should not be used" stuff ("dropped" category), the spec could also include a normative statement requiring conformance checkers to emit warnings for those. Or, handling of reporting for those could instead just be left up to the discretion of conformance-checker implementors.
mass-move component to LC1