In general, I don't really understand what problem this draft is
trying to
solve. A clearer statement in the abstract or introduction explaining
_why_ a common registry is a good thing would be very useful.
It might also be worth considering separating the Link: header and the
registry into two different specifications. This would also help
clarify
how a specification should refer to the registry.
Comparing relation types case-sensitively (e.g. as in 4.2 Extension
Relation Types) is incompatible with HTML's processing of rel=""; I
would
like to request that all relations always be case-insensitive.
The Link: header has a "rev" attribute. I would recommend dropping
it for
consistency with HTML5; we discovered in examining typical usage that
people generally didn't understand how to use rev="", and it is
redundant
with rel="" anyway. If it is kept, then please define how it works.
Allowing something but leaving it undefined is the worst of both
worlds.
(The ideal would be to define how it works but not allow it, IMHO.)
The link relations should better define how to handle interactions
between
multiple link types, so that alternate stylesheet can be well-defined,
and so that we can define rel="up up up" as in HTML5.
I recommend dropping the entire bit about profile="" -- while it
sounds
like the right thing to do, in practice almost nobody uses
profile="", and
the attribute has been dropped in HTML5. This is a lot of complexity
without a particularly compelling use case as far as I can tell.
The spec should clearly say which takes preference if both title= and
title*= are given. Also, the spec should clearly say which takes
preference if multiple title=, type=, etc, attributes are given.
I think for the best compatibility with legacy implementations, the
spec
should say that there must only be one occurance of each attribute,
and
that multiple link types in one Link: header should be listed in one
rel="" attribute. (That is, only allow rel="a b", not rel=a;rel=b.)
Unless there are really strong use cases, I think that the anchor=
attribute should be dropped. In practice, implementations today ignore
that attribute, which would mean that, e.g., a rel=stylesheet;anchor=a
link would fail to have the "right" effect. If it is kept, then the
right
behaviour for how this should integrate with style sheet linking
should be
defined in great detail.
I would like to request that each link type be defined as either
being a
hyperlink or an external resource link, as defined in HTML5, and that
this be added as one of the things that must be defined in the
registry.
Similarly, the registry should define whether or not link relations
are
allowed at the document level (<link rel>, Link:) and at the phrasing
level (<a rel>, <area rel>). Some types in HTML5 only apply to one
or the
other.
Ideally, I would like the Link: header section to more clearly
define how
some of the keywords defined in the spec should actually be used. For
example, how should the rel=stylesheet keyword affect the CSSOM?
Where do
resources imported in this way fall in the CSS cascade? How should it
affect documents with MIME types like text/plain? Do rel=icon links
interact with those specified in the document? If so, where should
they be
considered as falling in terms of tree order?
I would like to request that the registration mechanism be made
significantly simpler than the one described in the spec. For
example, a
simple mechanism could be just to edit a wiki listing all the
extensions.
I would like to request some guidance on what HTML5 would have to do
to be
compatible with this draft, and what benefits would come from it.
There
are clear benefits to the Link: header section, assuming that how it
fits
into the general Web platform is defined (as requested above). But how
does the registry fit into the RelExtensions registry for HTML5? How
should they interact?
The "up", "first", "last", and "payment" types are woefully
underdefined.
What is the expected UA behaviour when discovering a link with
rel=payment? What are the authoring requirements? What are the
implementation requirements?
Cheers,
--
Ian Hickson U+1047E )
\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _
\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--
(,_..'`-.;.'