Re: [draft-nottingham-http-link-header-06] concerns about Link header

> In summary I think the work around web linking (in Atom, HTML & HTTP) is
> some of the most exciting development in the space and I would strongly
> oppose abandoning it. I'd much rather use something everyone else is using
> than having to roll my own.

+1 

IMHO an area which is neglected and should get more attention. You're
invited to have a look at a technical report we've recently published [1]
and a service [2] we're building to support the discovery area (in early
alpha, so please bear with us ;)

Cheers,
      Michael

[1] http://linkeddata.deri.ie/tr/2009-discovery
[2] http://uldis.deri.ie/

-- 
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html



> From: Sam Johnston <samj@samj.net>
> Date: Mon, 31 Aug 2009 12:52:55 +0200
> To: Anne van Kesteren <annevk@opera.com>
> Cc: HTTP Working Group <ietf-http-wg@w3.org>
> Subject: Re: [draft-nottingham-http-link-header-06] concerns about Link header
> Resent-From: <ietf-http-wg@w3.org>
> Resent-Date: Mon, 31 Aug 2009 10:58:02 +0000
> 
> Anne,
> 
> I plan to use HTTP Link: headers with an API I am working on (
> http://www.occi-wg.org/) - primarily to advertise alternative
> representations, related resources, actions (start, stop, restart),
> collections (tasks), etc. and am very happy to have this function for
> non-hypertext resources (that is, those which are incapable of expressing
> links internally - like binaries).
> 
> I also see it as being a relatively lightweight option for semantic web
> applications and believe that this was the intention from the early days of
> HTTP development. The Link: header as well as the LINK and UNLINK verbs
> were, in my opinion, well ahead of their time, and were it not for hypertext
> stealing their thunder may well have comprised the "glue" of the web. We do
> need glue for non-hypertext formats and I struggle to come up with a better
> idea than the great work Mark et al have done already.
> 
> You are quite probably right about limited browser support but I don't think
> that matters - the clients of the future will necessarily be more
> intelligent than those of the past and even if traditional browsers never
> implement them fully I can already think of a myriad applications that could
> take advantage of them - one off the top of my head is using rel="license"
> to categorise the web into zones of reusability.
> 
> I also tend to agree with you regarding language support - with everything
> else dependent on negotiation I don't see why Link: headers should be any
> different. It doesn't help that there will be arbitrary limitations courtesy
> proxies, application layer firewalls, clients and client libraries so having
> potentially tens of additional titles could well cause breakage. The most
> important thing though, in my opinion, is consistency across standards. To
> that end a separate document describing generic link relations for
> incorporation into other standards could be useful (that is, Atom, HTML &
> HTTP would be implementations of that generic standard).
> 
> In summary I think the work around web linking (in Atom, HTML & HTTP) is
> some of the most exciting development in the space and I would strongly
> oppose abandoning it. I'd much rather use something everyone else is using
> than having to roll my own.
> 
> Sam
> 
> On Mon, Aug 31, 2009 at 12:26 PM, Anne van Kesteren <annevk@opera.com>wrote:
> 
>> I should probably have expressed my doubts earlier, but I don't really have
>> the feeling that implementing the Link header fully per specification is
>> really worth all the effort. In fact, dropping the limited support we have
>> seems like a more attractive option.
>> 
>> Having a UI for the <link> element never really took of in the decade that
>> it existed except for a few special values (which people are bitching about
>> on this list; "alternate stylesheet" is one of the few minor success
>> stories) and hoping that interest in implementing such a thing will revive
>> if we re-introduce the Link header seems misguided. Making the Link header
>> more complex than its counterparts by supporting localized titles also feels
>> way too much like some nice theoretical idea that might be implemented
>> correctly in a few clients but will hardly be used in practice. (It also
>> stops it from being semantically equivalent to the HTML <link> element, but
>> that is not stated. A bug?)
>> 
>> And while obviously lots of thought went into the specification, the
>> primary goal seems to be to getting it to RFC status rather than getting it
>> implemented in clients. There are no test cases, almost no checking of
>> existing applications, almost no requirements for clients in the draft.
>> 
>> This is also not a feature Web authors are asking for as far as I know.
>> (The implementation of the Link header in Opera was more done as a gimmick
>> and in retrospect we should probably not have done it.)
>> 
>> 
>> --
>> Anne van Kesteren
>> http://annevankesteren.nl/
>> 
>>

Received on Monday, 31 August 2009 11:32:33 UTC