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

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Tuesday, September 22, 2009 4:36 PM
 
> Whether the link type is allowed in the various places in HTML that take
> link types is necessary because otherwise the validator can't say whether
> the link type is being used correctly.

It only needs to care if the link types it *knows* are used correctly. This is like saying there is value for someone who doesn't speak Spanish to known whether someone speaking Spanish uses correct grammar. It is also impossible to keep the validation rules in sync with registries and implementations. And it is absurd to suggest that a monkey with a keyboard can add an entry to a wiki and the whole world will need to refresh their browser validation rules. If you are going to require UAs to do something with the registry wiki, you are going to need a process for approving entries.

> Whether the link type is a hyperlink or references an external resource is
> necessary so that UAs (like wget) can automatically support "save as whole
> page"-like functionality even in the face of relationships they don't
> support. (For example, it would mean wget doesn't need to be revved each
> time browser vendors come up with a new way to hook resource to a
> document, as they did with rel=icon, for instance; it could just update
> itself from the registry).

Is that it?? Is 'Save Page' the only use case for this? This idea that we should put all these rules and validation on relation types just so that a browser won't miss a linked document when it is saving a page is completely unjustifiable. The basic idea behind links expressed via a <Link> element is that they should be ignored if the client does not understand their semantics, whether they are registered, extension, or whatever.

> > For example, I have been using the relation type 'describedby' a lot
> > recently. It has different processing rules for LRDD, XRD, POWDER, etc.
> > But it *means* the same thing.
> 
> That seems like two contradictory statements. Surely the meaning of a
> relationship is the processing rules it requires. What else could a
> link type mean?

But the processing rules are context-specific and the context goes far beyond just the media type it is used it. I can write a protocol that uses HTML5 or ATOM documents and define my own processing rules for handling certain relation types. The context also includes what the client is trying to do.

For example, a relation type 'replacement' can be registered with a simple semantic meaning "a document which replaces the current document and makes it obsolete". A client fetching a document with such a link can choose to handle it by ignoring the current document and loading the replacement, by displaying it or archiving it first and then looking at the replacement, or it can use the document because it needs that specific document. And I'm sure there are more ways to handle this in the context of a search engine, identity protocols built on top of common documents, etc.

> If it's harder to register a link type in this registry than in HTML5's,
> then HTML5's will end up a superset, and we will have failed to accomplish
> the goal of avoiding clashes.

But the problem is not with the registry but with HTML5. You are proposing far more complex requirements for new relation types in ways that will impact the stability and performance of every compliant browser and UA in the world, but *this* is too much? The new registry is only asking for a published spec and consensus. You are asking for world domination... :-)

HTML5 should mitigate these concerns by putting in language that will require new short-name relation types to be registered. You can't have it both ways. Either HTML5 use of relation types is extremely strict, in which case you need strict rules about new relation types, or it is perfectly fine to ignore unknown types and move on, in which case you don't need another registry.

EHL

Received on Thursday, 24 September 2009 17:45:16 UTC