Brian --
Thanks for the feedback. Replies below...
On 23/04/2008, at 12:35 PM, Brian Smith wrote:
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?
I haven't engaged them yet; they're next on the list.
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 draft does not advocate removing links from Atom documents to put
them in headers; rather, the common use case is repeating them in
headers, so that they can be easily discovered and processed.
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.
Yes, that's the point of this approach.
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
vaguely-similar purposes.
Yes. I wanted to get feedback on the overall approach; I know they
need some work, and I'm open to suggestions for text.
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.
You're the first person to suggest that. I think we can get to a place
where there's alignment between the specs without abusing the
semantics of existing relations. It's certainly worth trying...
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
example?
A link relation shouldn't say that it's to be used in a particular
part of a format; that's up to a format to specify.
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.
Can you expand upon this?
Also, I think a lot of the discussion about decentralized media types
[1] applies to using URIs for link relations too.
[1]
http://steve.vinoski.net/blog/2008/02/11/more-about-decentralized-media-
types/
It certainly deserves some thought. Some escape hatch is necessary;
the question is how much its use should be encouraged...
Cheers,
Cheers,
Brian
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
Mark,
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
instance,
"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
--
Mark Nottingham http://www.mnot.net/
