W3C home > Mailing lists > Public > public-html@w3.org > August 2010

Re: Report on testing of the link relations registry

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 18 Aug 2010 08:55:56 +1000
Message-ID: <AANLkTik4EHO2yR1drkRYJk77PPbMk8BRwCt-At5JqzFP@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org
On Wed, Aug 18, 2010 at 8:35 AM, Maciej Stachowiak <mjs@apple.com> wrote:

> On Aug 17, 2010, at 3:11 PM, Silvia Pfeiffer wrote:
> Which organisation would you trust to be the most consistent about
> maintaining the registry? Would the WHATWG registry disappear and just point
> at the Microformats registry as the authoritative one? Or the other way
> round?
> Since both, the WHATWG and the Microformats are more "living" lists, i.e.
> take on experimental work as well as an interim list, could they be used as
> contributors to the IANA list, where only the well-accepted ones get listed?
> If so, maybe a simpler process for moving something from the
> Microformats/WHATWG list into the IANA list could be determined?
> It actually seems to me that the W3C is standing in the middle of three
> other organisations that are trying to claim authoritative registry status
> for different reasons and we are only moderating because we have a big stake
> in the use of the names. Are we even in a position to resolve this or is
> this just a random discussion?
> I don't have very strong feelings about how to resolve this, other than
> thinking it's time to get other proposals written up and on the table. But I
> wonder if, based on what you say, a proposal like this could work:
> - The Microformats wiki (or some other extremely lightweight mechanism,
> perhaps hosted by W3C), will be considered the canonical registry for
> "provisional" state link relations.
> - Assuming the Microformats community is willing, we enhance the
> Microformats wiki with the information needed for HTML5 (i.e. whether each
> relation applies to <a>, <link> or both, assuming HTML5 continues to make
> this distinction).
> - The IANA registry will be considered the canonical registry for
> "accepted" state link relations.
> - If the Designated Experts for the registry are not willing add the fields
> needed for HTML5 (i.e. whether each relation applies to <a>, <link> or both,
> assuming HTML5 continues to make this distinction) but the Microformats
> community is, we can use the Microformats wiki as the canonical place for
> this information.
> For registrations of link types defined in the HTML5 draft itself, can we
> find some way past the issue of what URL to reference?
> My suggestion: provide the TR link as the canonical long-term reference
> (that is where the CR/PR/REC versions will live) as well as an Editor's
> Draft link as a short-term informative reference. Once HTML5 goes to CR and
> later stages, it's very unlikely there will be changes to the spec. If
> future versions of HTML change some link relations, then it would be
> appropriate to re-register at that time. So it seems to me this fits the
> model. A "provisional" registry could of course point straight to the
> editor's draft if that seems more appropriate.
> I believe such an approach would play to the respective strengths and
> established track records of the Microformats community and the IANA/IETF
> community, and would strike the right balance between lightweight
> provisional registration and carefully considered full registration.
> I am curious if WG members would find an approach like this reasonable.
> Regards,
> Maciej
That's exactly what I had in mind. In addition to that, people need to be
given instructions on how this actually works. Thus, I would suggest that
the process needs support from both organisations:
* IANA should put up a Web form to submit registrations with all the details
to make it simpler to submit
* Microformats should point to the IANA Web page
* IANA should point to the Microformats page to encourage people to use it
for initial registrations until the new proposal has found enough support

Received on Tuesday, 17 August 2010 22:57:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 August 2010 22:57:04 GMT