[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Fwd: I-D ACTION:draft-nottingham-http-link-header-01.txt
James M Snell wrote:
> Mark Nottingham wrote:
> > Hello Atom-ers,
> > I'd like opinions on the draft below; it proposes some changes to
> > facilitate alignment of the HTML and Atom link relation values and
> > registries, so that we don't have format-specific link relations.
> > Feedback has been positive so far (mostly on the HTTP list,
> also in W3C
> > circles), but since this changes the registry (and otherwise is so
> > directly related to Atom), it's important that there's
> buy-in here as well.
> > Comments?
The HTML5 draft document says that Link: headers are to be processed
according to the definitions given in HTML 5. I vaguely remember that
the HTML WG (or WHATWG, I forget) wanted to be the authoritative
reference for all link relations in HTML, they wanted to define how
conflict are handled, and they even have their own wiki-based registry:
http://wiki.whatwg.org/wiki/RelExtensions. What did the HTML 5 people
have to say about shifting the maintenance of the registry to the IESG?
Is a Link header is even a good idea for Atom documents? Atom documents
are almost universally machine-generated, and it is easy for a generator
to just add the appropriate <link> element to the document, instead of
adding a Link header. Most Atom clients do not look for Link: headers
anyway, so you have to put them in the document if you want them to be
found. Splitting the information between the headers and the document
just makes processing Atom documents more difficult.
The precise meaning of each link relation should be defined in a way
that doesn't depend on the content type of the variant being returned.
Some of the definitions in the draft are too vague, and when you follow
the references to the more precise definitions, those definitions are
either Atom-specific or HTML-specific. Vague definitions will lead
different people to use the same link relation for different, but
For all those reasons, I actually think it makes a lot more sense for
the Link header registry to be mutually exclusive with the HTML and Atom
registry, instead of attempting to merge them all together.
The current draft says "[A] link relation SHOULD NOT specify what the
context of its use is, although the media type of the dereferenced link
may constrain how it is applied." I don't understand what that means; it
could be read as saying that the precise meaning of the link depends on
the target's media type. Is that what you meant? Could you give an
In the introduction, in explaining the motivation for standardizing the
Link header, the draft says "[T]he status of the Link header is unclear,
leading some to consider minting new application-specific HTTP headers
instead of reusing it." I agree that application-specific HTTP headers
are problematic; however, the Link header only addresses the case where
the application-specific header is a hyperlink; it would be better to
solve the problem more generally.
Also, I think a lot of the discussion about decentralized media types
 applies to using URIs for link relations too.
> Sent: Wednesday, April 23, 2008 8:37 AM
> To: Mark Nottingham
> Cc: atom-syntax Syntax
> Subject: Re: Fwd: I-D ACTION:draft-nottingham-http-link-header-01.txt
> overall I think this is a good thing. However, I am
> concerned that this
> would allow for a bunch of new link relations to be used in
> Atom without
> a clear understanding of their meaning in that context. For
> "index: refers to an index" is not exactly clear and the
> description in
> HTML 4.01 doesn't help either "Refers to a document providing
> an index
> for the current document." It is an index of the Atom entry
> or of the
> content? It's not a showstopper, of course, but it is something that
> should be considered.
> - James