Re: Report on testing of the link relations registry

Eventually all registries held by a standards organisation go the same way
and become bureaucratic and difficult to use, because that is a way to
protect against spam registrations (and other annoying stuff). I believe if
we set up another registry, we will eventually run into the same problems -
not to speak of potential conflict with the existing IANA registry. So, what
is the next generation of Web standards developers to do? Create a Google
wave based registry on top of the then existing two registries? (yes, I
know, Google wave is dead - I'm just using it as a placeholder for the "next
big technology for document authoring on the Internet").

Isn't there a better way where we can help IANA fix their registry to do
what we need it to achieve? Isn't this what harmonisation between standards
bodies is all about? Also, I'm not suggesting that Ian should do this - in
fact, I think this is totally the job of somebody in a different position to
an editor in the W3C. It's good to know where it's up - but I think now it's
time to plan with IANA a new process that allows us all to move into the
future.

Cheers,
Silvia.


On Tue, Aug 17, 2010 at 5:52 AM, Leif Halvard Silli <
xn--mlform-iua@xn--mlform-iua.no> wrote:

> Maciej Stachowiak, Mon, 16 Aug 2010 11:16:11 -0700:
> > On Aug 16, 2010, at 2:54 AM, David Singer wrote:
>
> > I found these pieces of information notable, because:
> >
> > (a) The suggestion of an additional/parallel HTML-specific link
> > relation registry is not in line with the current ISSUE-27 Change
> > Proposal, which calls for using the IANA registry exclusively (so
> > perhaps now is a good time to call for alternate proposals).
> >
> > (b) Given the above pieces of information, it seems that the current
> > ISSUE-27 Change Proposal, if not revised, could have significant
> > normative impact beyond just the registration mechanism for link
> > types.
>
> It would interest me to hear in what way you foresee this "significant
> normative impact". Care to explain?
>
> The most important - and unsurprising - info I have heard is that the
> Link Registry wants to be a registry for stable relations.  Whereas Ian
> wants a "live" registry that "matches reality". (I follow the link
> registry list - I did not pay much attention to the "diary" that Ian
> posted here.)
>
> The point with the registry is, I think, that it should document link
> relations that are the same everywhere. Thus it is supposed to document
> _that_ reality. This puts a pressure on link type specifiers to define
> language unspecific relations: once defined, one cannot change a
> relation only in order to match reality in just one of the
> languages/specs where the relation is useful.
>
> Despite that Julian says that is not hard to send register a relation,
> I think another purpose with the registry is to make sure that the
> energy spent on defining link relations, can be reused also in other
> specs etc.
>
> By the way - Bug 7475 is exactly about this: Ian wants to change some
> relations. He even admits that the changes he suggests are dramatic:
> [1] "the definitions in HTML5 rock the boat". Whereas I and some others
> wants to maintain the relations as defined in HTML4, XHTML1 etc stable.
> Neither authors or implementations should experience that link
> relations changes meaning under their feet.
>
> That said, not all link relations needs to be the same everywhere.
> HTML5 could define a link relations profile: If you use HTML5, then you
> also accept only the HTML5 profile as valid. Via the profile attribute
> - supported by extensions to HTML5 and in other HTML dialects - one can
> anyhow override any link relation semantics. Of course: only in those
> UAs which support profile. Thus, in practice, not really ... Which
> again calls for stable and shared link relation semantics. However, the
> @profile thing demonstrates that not everything need or can be in the
> registry.
>
> But also: Not everything in the registry needs to be in HTML5. I think
> it  - long ago - is too late to make <!DOCTYPE html> become a kind of
> versioning signal which signals that some link relations will be
> interpreted differently when using that doctype. At best, HTML5 could
> make some link relations forbidden in HTML5 documents - without
> changing their meaning.
>
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7475#c5
> --
> leif halvard silli
>
>