Re: Report on testing of the link relations registry

On Fri, 3 Sep 2010, David Singer wrote:
> 
> Wikis can be dynamic, open, up to date, and so on.  But the downside is 
> that anyone can edit them

That's an upside, not a downside.


> enter poorly-thought-out ideas

We _want_ the poorly-thought-out ideas in the rel registry -- we want 
anything that's being used, or may be used soon, or that has or will soon 
have implementations, whether or not they are good ideas. That's the whole 
point of having a registry -- it lets you avoid clashes and lets you find 
out what values mean, however ill-designed they may be.


> incorrect information

Registries can have incorrect information too (see the character encoding 
registry for a clear case of that); the difference is that wikis are much 
more likely to be fixed (witness how the recent effort to fix the 
character encoding registry started on a wiki and then stalled when it 
came to actually updating the registry!).


> change existing state

That's an upside, not a downside. States change. There shouldn't be 
gatekeepers in the way of getting that information into the registry.


> and so on. To gain that dynamicity they lose trustability ("don't use 
> Wikipedia as a primary reference" for example).

I would posit that the quality of data on a wiki for link relations would 
be higher than the quality of data in a registry for link relations, 
precisely because of what you describe as downsides. As evidence for this 
argument I present the link relation registry (which is a formally run 
registry) and the wikis (at least one of which isn't even actively 
maintained currently).


> I think that registries should be optimized for readers -- for 
> stability, clarity, correctness, and ease of lookup, and that Wikis tend 
> to be optimized for the authors, rather than the readers.

I disagree with this premise. Compare the readability and clarify of the 
link relations registry to the Microformats or WHATWG wikis for rel="" 
attributes, for instance (and consider that the WHATWG one isn't even 
actively maintained, as mentioned above).


> I just want to avoid a situation in which people 'just know' that some 
> random wiki pages are really considered definitive, some are helpful, 
> some off the mark, and so on.  The spec. and the registry should 
> reference each other, ideally, so we all know where we are.

I agree with that. The HTML5 spec currently references the WHATWG wiki for 
this reason. We should definitely change it to point to whatever solution 
the world is actually using, regardless of whether we think it's what 
should be used or not. The spec should reflect reality, not ideals.


> I have no problem with a spec. that says "experimental link relations 
> are often documented on <wiki>, until they are stable enough and used 
> enough to be considered fixed, when they move to <the formal 
> registry>.", for example.

I do. We should never consider something "fixed". That's not how the world 
works. Sometimes meanings drift, and the specs should drift with them.


> So, let's decide what is needed in a registry, ("the specification of a 
> link relation must say X, Y, Z or have a reference to a document where 
> those are specified") and how we want to operate it, and I am sure we 
> can arrive at a sensible result that will last.

I think it should include the information described in the spec as being 
needed in the registry, and that the barrier to entry for adding an entry 
to the registry should be that either the relation is actively used or 
implemented, or will soon be used or implemented, and that no further 
information should be required but that a specification should be 
encouraged, to help interoperability.

I think we should operate the registry as an openly editable Web page with 
an open-ended free community of volunteer editors to maintain quality.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 4 September 2010 00:12:34 UTC