W3C home > Mailing lists > Public > public-rdf-wg@w3.org > August 2011

Re: JSON Emergency Brake

From: Dan Brickley <danbri@danbri.org>
Date: Fri, 26 Aug 2011 13:06:03 +0200
Message-ID: <CAFNgM+bNPrj95mm9egggKESyzUcL2CikqJcXCDrwFx34K2rQAQ@mail.gmail.com>
To: Richard Cyganiak <richard@cyganiak.de>
Cc: Thomas Steiner <tomac@google.com>, Alexandre Passant <alex@seevl.net>, RDF WG <public-rdf-wg@w3.org>
On 26 August 2011 12:35, Richard Cyganiak <richard@cyganiak.de> wrote:
> On 26 Aug 2011, at 08:41, Thomas Steiner wrote:
>>>> "Link headers, the mullet of the Web: business in the front, party in
>>>> the back. Idea: serve #JSON, make it #jsonLD by a @context Link
>>>> header."
>>> Are you talking about the Link: HTTP header? That doesn't make sense. Why would you use an HTTP header for something that's specific to a single representation format? What's the advantage over putting it into the representation format?
>> I am indeed talking about the HTTP Link header. Why shouldn't it make sense to use it?
> It's really easy to include the link in the representation format. For many developers, it's harder to set an HTTP header. So it increases the risk that people just won't do it, and it increases the cost of using JSON-LD.
> You may think that setting an HTTP header isn't hard, but believe me, you're wrong. This is one of the things I've learned from the whole 303 mess.
> Also, I can see absolutely no advantage to using an HTTP header here.

This is pretty clear. We've tried HTTP header -based design, and it
has been pushed pretty heavily via Linked Data evangelism over the
last few years. It was a hard sell.

(as I write this, Thomas' mail arrives, clarifying that headers would
be only as added extra)

But still, from me a -1 on using headers. They are problematic for
most developers and almost all publishers, and if there are also other
ways of expressing the same thing, that introduces complexity when the
two are simultaneously used differently.


Received on Friday, 26 August 2011 11:06:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:08 UTC