Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

On Wed, Sep 16, 2009 at 9:44 AM, Ian Hickson <ian@hixie.ch> wrote:

> If the link registry isn't going to be providing this, then it's not
> really solving the problems for which HTML5 needs a registry.
>
> I guess to avoid name clashes the HTML5 link registry can require that the
> link type be registered with your registry and that the semantics defined
> for HTML5 be consistent with those referenced by the specification given
> in the registry.


Right, as I see it specifications should define concrete relations either
with reference to existing generic relations or by specifying new ones. HTML
does not yet do this if I understand well, but it would be a simple change
to add an IANA petition.

For example, I was looking for a relation to describe the "most recent
version" of a resource (as distinct from a specific version in a VCS). I'd
have used "current" were it not for its definition in RFC 5005 as "a feed
document containing the most recent entries in the feed" (for which 'recent'
would have been a better term IMO). Now I need to either try to shift the
existing definition or find another like 'latest' - without regard to the
registry we'd have ended up with two conflicting definitions.


> > Do you have concrete suggestions for the IANA process to be used?
>
> I would suggest that the IANA host a wiki that anyone can edit.


Agreed, a generic version of the
RelExtensions<http://wiki.whatwg.org/wiki/RelExtensions>wiki page
would be perfect.


> > > > I'd agree that "payment" is ill-defined, but most of the questions
> > > > you ask need to be answered (once again) in the context of a
> > > > particular application of linking, not by the registry.
> > >
> > > So how rel=payment works will differ for Atom and for HTML?
> >
> > No. As far as it goes, it doesn't work at all at the moment, AIUI; i.e.,
> > a UA is free to ignore the relation type and treat it link any other
> > link (which is as it should be). I'm not sure what the automated cases
> > for it are.
>
> Does it not have a specification that defines this?


The existing definition as "a resource where payment is accepted" seems
adequate to me - in a UI a prefabricated link to PayPal would suffice but
for automated mechanisms there will presumably be some competition, with
each having its own content type.

I don't think there's much point having a single registry then. We should
> just have different registries for each linking mechanism, if that's going
> to be the practical scope of the registry anyway.


There are applications which meed to span multiple formats - for example
OCCI has Atom and XHTML renderings and it would be intensely confusing if
there were different relations for the same LINK element depending on the
format (not to mention if these were conflicting!).

I see Mark's proposal as a great way to achieve inter-format
interoperability - something which will be increasingly important as we move
forward.

Sam