Rel Registry at the W3C

Written by Henri Sivonen

Summary

A registry for rel tokens has been identified as a need for HTML5. This Change Proposal proposes that the registry be hosted by the W3C following the precedent of the XPointer scheme registry.

Rationale

Hosting the rel registry on the WHATWG wiki was met with some resistance. In 2007, it was proposed that the registry be delegated to microformats.org. Then the discussion turned to hosting it at the w3.org. Then, for a long time, the working assumption was the the registry would be hosted by the IANA.

Now that the IANA registry has been established, it has turned out that the process to get a link relation registered is more heavy-weight than some stakeholders deem appropriate. Particular points of concern include:

1. The person registering a link relation can't have the relation appear in the registry with a single registration action but is on the hook for defending his/her registration over the course of multiple email round trips to the Designated Experts and during this time the relation doesn't appear in the registry.
2. Registrations in the IANA registry are requested to be generic beyond HTML. Requiring the person who is about to register a rel token for use in HTML formulate the definition of the token in more abstract terms raises the barrier for entry. There isn't general agreement that a higher level of abstraction and generality is worth the trouble.
3. Changing how the IETF/IANA operate to satisfaction seems to involve considerably more discussion and time than setting up an HTML-specific rel registry elsewhere.

Since the proposed solution of using an IANA registry seems to involve too much bureaucracy in order to get a relation listed even as a provisional registration, it makes sense to go back to the alternatives suggested back in 2007. The W3C is already in the registry business in the form of the XPointer scheme registry, so there's both process precedent and existing software for implementing a registry at the W3C. To lower the barrier to registration compared to the IANA process and to avoid making the HTML community bear the burden of abstracting link relations for use outside HTML, there should be a low-barrier registry hosted by the W3C.

Details

1. Deploy a copy of the software running http://www.w3.org/2005/04/xpointer-schemes/ at an undated URL under http://www.w3.org/html/ (e.g. http://www.w3.org/html/link-relations/)
2. Modify the copy to talk about HTML link relations instead of XPointer schemes in the UI.
3. Modify the software to reject registrations with the letters A (U+0041) to Z (U+005A), inclusive, in the token being registered unless the token also contains a colon (U+003A). Make the software reject registrations with any of the characters U+0000, U+0020, U+0009, U+000A, U+000D or U+000C in the token being registered. Document these restriction in the UI. Allow other values.
4. Add language to the registry page that says the registry (i.e. the output of the registry program) is licensed under the W3C 3-clause BSD license (or the MIT license, but BSD seems less controversial, since the W3C already uses BSD for test suites)
5. In the UI for registering a value, add language that says the submitter of a registration agrees to the submission text being licensed under the license of the registry.
6. Change the software to support the fields described in the Other link types section of HTML5.
7. Make the output HTML (i.e. the registry page) easy to scrape by marking up the above fields in the output using HTML elements with class names indicating the fields.
8. When a user registers a value in the system, it should become visible with the "proposed" status.
9. Make the existing registry values modifiable by users. (It seems the XPointer registry software already supports this--mentioning it to be explicit.)
10. Create a mailing list and make the registry software send the audit trail of additions and modifications to the list. (It seems the XPointer registry software already has this feature.)
11. Make it possible for the W3C staff to completely delete spam items from the registry view.
12. Create a policy page that communicates the following policy points:
    1. The registry is licensed under the W3C 3-clause BSD license.
    2. Anyone with a W3C account (including a public account) may use the system to register a rel value subject agreeing to the publication of the registration under the license of the registry.
    3. People are encouraged to reuse existing values that fit their use case in preference to registering new ones.
    4. Registry entries start in the "proposed" state.
    5. A registry item may be marked as being "ratified" if the value has been approved in the Microformats process by the Microformats community or has been published as a Last Call draft or higher by the HTML WG of the W3C.
    6. A registry item may be marked as being "discontinued" if the value has been explicitly rejected in the Microformats process by the Microformats community or in a Last Call draft or higher by the HTML WG of the W3C.
    7. The W3C staff may remove registry entries deemed to be spam on a "we know it when we see it" basis.
    8. The description text must be in English.
13. Add language to the registry page encouraging people to submit new rel values to the registry before deploying them. Link the encouragement to the more detailed policy page.
14. Change the Other link types section of the HTML5 spec to link to the above-described registry instead of the WHATWG RelExtensions page. Specifically:
    1. s/the Wiki page/the registry/
    2. s/the Wiki/the registry/
    3. s/Anyone is free to edit the WHATWG Wiki RelExtensions page at any time to add a type./Anyone is free to submit a registration to the W3C HTML rel value registry at any time to add a type./
    4. s/WHATWG Wiki RelExtensions page/W3C HTML rel value registry/g
    5. Change links that previously pointed to the wiki page to the registry.
    6. Reference the registry where [WHATWGWIKI] is now referenced.

Impact

Positive Effects

• People will be able to register HTML-relevant rel values with less bureaucracy than at the IANA, which may lead to the registry better reflecting usage.
• The HTML WG can proceed without getting further entangled in trying to change IETF or IANA policies or practices.
• People registering rel values don't need to consider how to generalize their registration to apply to other formats, such as Atom or PDF.
• Compared to the WHATWG wiki, the registry will be maintained on a site with multiple sysadmins responding to failure situations and with more resources to enable the longevity of the registry URL.

Negative Effects

• HTML-specific registrations might not be reusable in other contexts with the same semantics.
• Registering the same token with different meanings for HTML and another format that uses "rel", such as Atom, might cause confusion.
• The registry would be not be the Microformats Wiki even though the Microformat community has the best track record for running a registry of rel values.

Conformance Classes Changes

None.

Risks

Multiple registries for rel values may cause some confusion. Operating a registry at the W3C may not be viewed favorably by people operating competing registries. With a W3C registry in place, people might still not bother to register values or might opt to register them in one of the competing registries instead.

References

• ISSUE-27
• TPAC session minutes on the topic
• XPointer scheme registry