[Bug 12612] New: make rel value prohibitions in the spec and microformats wiki match

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

           Summary: make rel value prohibitions in the spec and
                    microformats wiki match
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: mike@w3.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


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.

-- 
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 Thursday, 5 May 2011 23:56:59 UTC