Allowing "application/xml" and "application/json" for .rdf and .jsonld data download

[ColinMaudry]

I'm setting up my personal RDF profile http://colin.maudry.com/id/me.ttl, my URI being http://colin.maudry.com/id/me.

I have uploaded this Turtle file to http://dydra.com/colin-maudry/me in order to enjoy the mutliple formats supported by Dydra for dumps.

I have set up an .htaccess that redirects requests to http://colin.maudry.com/id/me based on the accept headers.

I experimented a bit, and saw that if accept headers were not exactly the content type of dump serialization, Dydra returned a 406 Not Acceptable

$ curl -IL -H "Accept: application/xml" http://colin.maudry.com/id/me
HTTP/1.1 303 See Other
Server: Apache/2.4.12
Location: http://dydra.com/colin-maudry/me.rdf
Content-Type: text/html; charset=iso-8859-1
Content-Length: 243
Accept-Ranges: bytes
Date: Fri, 17 Jul 2015 19:55:23 GMT
Connection: keep-alive
Via: 1.1 varnish
Age: 0

HTTP/1.1 406 Not Acceptable
Server: nginx/1.4.6 (Ubuntu)
Date: Fri, 17 Jul 2015 19:55:23 GMT
Content-Type: text/plain; charset=UTF-8
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: *
Access-Control-Allow-Headers: Authorization, Content-Type, X-Requested-With

Since an RDF/XML is also an XML file, don't you think it would make sense to accept this content type? That also applies for application/json and application/ld+json. That would support the case where newcomers to Linked Data don't know the specific content types.

This is low-priority, I thought it was worth asking.

[ColinMaudry]

There is also the case of Javascript frameworks (eg. JQuery, AngularJS) that, when asked to GET a URL, pass application/json as content type by default. You don't want developers to be forced to fiddle with their get() method, right? :)

[lisp]

we thought about permitting this, as well as about permitting other legacy media types. we were not able to find a satisfactory answer to the question, "what is the concrete response content type?". what is right answer?

[artob]

As James stated, we do believe it's better to mandate precise content types here.

After all, is application/xml to mean RDF/XML (an acknowledged legacy format that doesn't even know about graphs) or TriX (a fairly reasonable quad format), both which are XML? Is application/json to mean RDF/JSON or JSON-LD? When JSON-LD was introduced, should we have changed it from RDF/JSON (the only thing it could have previously meant) to JSON-LD? What about when the next great thing--i.e., the next thing after the rather complicated JSON-LD--eventually comes along?

It's true that makers of client apps will have to figure out how to send a correct content-type header, but that's something we can at least facilitate by providing extensive copy-and-paste examples in our documentation. (The current docs are inadequate in this regard, admittedly.)

Note also that application/xml is in fact reserved for the XSLT post-processing pipeline (currently wholly undocumented, as far as publicly-available features go--but I believe you know how to use it, from previous endeavors).

[ColinMaudry]

I think there are two situations:

The user wants to POST (Content-Type) or GET (Accept) data, from a catch-all URL, and the server, based on the provided headers, redirects the request or does something specific. If the content type in the headers is fuzzy or not supported, it returns a 400 or 406. In this case, since the server needs to be smart about how to interpret the request, I understand that application/xml would be too fuzzy, since it could mean TriX or RDF/XML.

The other case, that I describe in this ticket, is slightly different. In this case, I hit a URL that requires no logic from the server. If I GET http://dydra.com/colin-maudry/me.rdf, whether I provide application/xml, application/rdf+xml or no "Accept" headers at all, it's quite obvious that I want to retrieve RDF/XML content because of the extension. I know file extension can sompetimes be misleading, but if they really weren't reliable, you would have simply exposed http://dydra.com/colin-maudry/me and let content negotiation, with strict Accept headers, do the magic.

[lisp]

you note, that, "I know file extension can sompetimes be misleading, but if they really weren't reliable, you would have simply exposed http://dydra.com/colin-maudry/me and let content negotiation, with strict Accept headers, do the magic."

yes, that is the direction we intend to follow.