DataLink MIME types

[Norman Gray]

Greetings, all.

Following on the current datalink-terms discussion, I've just looked at the DataLink PR document with a particular REST-shaped question in mind.  I found that I couldn't get a satisfactory answer to the question.  I forget which precise stage the document is at, but I'll log this here anyway.

I'm not suggesting these are blockers (thought the broken reference should be fixed).

I wanted to ask: would it be possible for a client to ask for the links response in a format other than VOTable, via an Accept header, and would it be permissible for a service to provide it in a different format?  In my mind, obviously, is allowing a service to provide a Linked Data style response, meaning that the response is in one or other RDF syntax. (DataLink is a poster-child Linked Data application -- note, I'm not suggesting that it's a priority to do this, but I would hope that the spec would make it permissible for an intern to implement it one afternoon in future)

0. Reference [1] points to <http://www.ivoa.net/DALI/>, which is a broken link.  It should be <http://www.ivoa.net/documents/DALI/>.

1. A REST-style GET of this URL would imply that the client could make its GET request with an Accept header.  If that's 'application/x-votable+xml', that's fine, but it should be at least permissible to give a different Accept header (such as text/turtle, for example).  If the service can't supply that, it's supposed to reply '406 Not Acceptable'.  I can see that it would be permissible to request a links resource with ?RESPONSEFORMAT=text/turtle, and permissible for a service to reply with such content (so the answer to my original question is 'partly yes').  Is it permitted, however, for a service to respect the Accept header? (this would probably be a more normal pattern in a Linked Data context).  

2. Specifically, if I supply Accept:foo/bar in my GET request to <http://example.org/foo/links>, should I get a 406 response, rather than a 200 VOTable? (I think the answer is 'yes').

3. I will ritually remark that the x-* media subtype is deprecated, and that the process for registering new subtypes (such as application/votable) is intended to be streamlined compared to what it was before.

4. Clarity: It might be worth a cross-reference from Sect. 3.1 to the discussion in the second paragraph of Sect. 3.3.  They overlap in what they're saying, but the latter makes a much stronger warning against a dumb string comparison than the former.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK