DataLink MIME types

[Patrick Dowler]

I think all of these are excellent points that belong on the TCG review 
section of the RFC page:

http://wiki.ivoa.net/twiki/bin/view/IVOA/Datalink1RFC

I'd prefer to address them there and CC the list, rather than the other 
way around, which makes work for François  and MArco :-)


On the general point:

It is within the spirit of all DAL specs that you can extend behaviour, 
so as long as RESPONSEFORMAT works as expected and your extra stuff 
won't mess up a client that uses the standard it should be OK. So if it 
was me, I wouldn't feel guilty about implementing Accept support in a 
datalink service for my own purposes. If the spec language on 
RESPONSEFORMAT is too strict to allow it, that is not the intent and 
should be noted on the TCG review.


Pat

PS-Fixed broken link already so no need to duplicate that one :-)



On 21/10/14 03:37 AM, Norman Gray wrote:
>
> 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
>
>

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)