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 vaguely-similar purposes. 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 example? 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 [1] applies to using URIs for link relations too. [1] http://steve.vinoski.net/blog/2008/02/11/more-about-decentralized-media- types/ 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 >
