- From: Eran Hammer-Lahav <eran@hueniverse.com>
- Date: Wed, 16 Sep 2009 16:59:35 -0700
- To: Ian Hickson <ian@hixie.ch>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
> -----Original Message----- > From: Ian Hickson [mailto:ian@hixie.ch] > Sent: Wednesday, September 16, 2009 12:44 AM > I think this basically makes the registry worthless. At least for > HTML5, > there are several aspects that we need to have in a machine-readable > fashion for each link type, including: > > - whether the link type is allowed on <link> > - whether the link type is allowed on <a> and <area> > - whether the link type is a hyperlink or references an external > resource Why? The whole point of relation types is that if you see one you don't understand you simply ignore it. It is perfectly reasonable to define a required set so that clients get consistent results using a baseline. But to try and enforce the introduction of new relation types like they were an XML schema goes against the very nature of the mechanism. It's like requiring <A> links to have "value" and be "relevant". > 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. It gives HTML5 a consistent semantic meaning without imposing rules on how you utilize that relation. It ensures that developers using multiple technologies don't have to use the same relation type with different semantic meaning which causes mistakes and abuse. Machines don't care about whether a relation type is an English word or a binary array. People do. And it would be a significant improvement it we could have a single registry to define what is the meaning / intention of this short relation type. 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. LRDD and POWDER both use this relation type in HTTP headers, but it is the context of the application and not the transport that dictates its meaning. If an application needs something more precise and would like to enforce more rules on it (such as cardinality), it should define an extension URI relation type. > 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. This would be the right way to handle this. In the future, if many technologies will find it useful to define such custom registries for their own processing rules of relation types, it might make sense to enhance the common registry to hold such information. But given the very different styles of managing such registries (IANA vs. wiki, etc.), it will probably be hard to find a common way to record the information and keep all these different communities happy. > I would suggest that the IANA host a wiki that anyone can edit. That is a horrible idea. The registration and semantic meaning of common terms for relation types should be based on wide consensus and not random whims of individuals changing a wiki. We are talking about cross-protocol cross-community registry to establish common basic terminology. Making it lightweight is really not a priority. EHL
Received on Thursday, 17 September 2009 00:00:13 UTC