RESPONSEFORMAT (was: Summary -- Re: Datalink Feedback)

[Patrick Dowler]

OK, I have thought about it....

On 22/04/14 03:34 PM, Patrick Dowler wrote:
> 2. (yet) I'm still thinking about how to clarify RESPONSEFORMAT

I propose to strip this section down to the bare minimum so that this 
parameter is there (in compliance with DALI) only to allow an 
implemention to have their own custom output formats. This basically 
means that it will be clear that clients can ignore this parameter if 
they want the standard VOTable output and services must return the 
standard VOTable if there is no RESPONSEFORMAT or if RESPONSEFORMAT is 
application/x-votable+xml[;<params].

While Markus has outlined the perils of using MIME types as values, I 
think we can get away without saying much here. In my opinion, it is 
safe for the service to ignore parameters (if present), but only because 
DataLink specifically mandates TABLEDATA format. (If we move on to 
TAP-1.x and we want to allow clients to pick the VOTable table 
serialisation, then TAP-1.x (or DALI-1.x) will have to be more explicit 
about MIME type parameters.)

In DataLink, the service only has to grok

* no RESPONSEFORMAT
* RESPONSEFORMAT=votable (DALI shortcut)
* RESPONSEFORMAT=application/x-votable+xml (strip and ignore params)

If they accept other values, that is custom behaviour we allow. Using 
this approach, the only thing an implementation cannot do is let people 
request (and return) VOTable with BINARY (eg) serialisation using the 
official MIME type. They would have to define a new/custom shortcut.

I would also completely remove Section 3.3.2 (Text output) and for 
errors we would allow custom error document format if someone implements 
custom response format... but the standard error document would be VOTable.

Does that simplify this enough to be un-thorny?


-- 

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)