This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12612 - [registries] make rel value prohibitions in the spec and microformats wiki match
Summary: [registries] make rel value prohibitions in the spec and microformats wiki match
Status: RESOLVED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P3 trivial
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard: reg
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-05 23:56 UTC by Michael[tm] Smith
Modified: 2011-11-20 18:19 UTC (History)
6 users (show)

See Also:


Attachments

Description Michael[tm] Smith 2011-05-05 23:56:57 UTC
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.
Comment 1 Michael[tm] Smith 2011-08-04 05:33:50 UTC
mass-move component to LC1