Datalink feedback IV

[Markus Demleitner]

Hi Mark,

On Fri, Mar 28, 2014 at 12:29:51PM +0000, Mark Taylor wrote:
> On Fri, 28 Mar 2014, Markus Demleitner wrote:
> > Considering this, I propose to only keep the first paragraph of 3.3
> > and then add
> > 
> >   The content-type header of the response MUST be set to
> >   application/x-votable+xml;content=datalink unless the incoming
> >   request had a DALI RESPONSEFORMAT parameter, in which case
> >   content-type follows DALI's rules.
> 
> Minor quibble: that would outlaw response content-types of for instance
> 
>     application/x-votable+xml;serialization=BINARY;content=datalink

That we indeed *want* to outlaw, because (as a service to, e.g.,
simple javascript clients) datalink responses must be in TABLEDATA.

>     application/x-votable+xml;content=datalink;charset=iso-8859-1

That's a valid point, yes, although I'd certainly discourage
the use of charsets in any XML MIME type, as XML defines its encoding
inline.

> or even
> 
>     application/x-votable+xml; content=datalink
>     application/x-votable+xml;content="datalink"

Another valid point.  All this is nasty because a service
implementation may not even be able to fully control the
*serialization* of the content-type header to the level of whitespace
or possibly the sequence of parameters; think, e.g., HTTP layers
doing content negotiation.

But, while I'm all for not constraining things such that code
compliant with upstream standards may break us, this:

> This would probably not cause problems in practice, but it would be
> more robust to say something like:
> 
>     ... MUST give a type/subtype of "application/x-votable+xml" with
>     the "content" parameter set to "datalink"
>     (e.g. "application/x-votable+xml;content=datalink") ...

is also not quite ideal.  The reason is that we don't have a MIME
parser in ADQL.  That is relevant because we're using the MIME type
as an identifier for "datalink response" in Obscore.  This in turn
means we cannot really relax 3.1 unless we officially disclaim the
use case

  Select all rows (not) returning datalink documents...

from obscore (or add a mime parser to ADQL such that we could say
  
  WHERE ivo_mime_type(access_format)='application/x-votable+xml'
    AND ivo_mime_get_parameter('content, access_format)='datalink'

).  Actually allowing more parameters and free whitespace into this
identifier will also make identification of recursive datalink
services harder, though there we can specify requirements on clients
and could just say: parse the mime or perish.


There are various highbrow ways to clean up this mess (involving not
using complicated things like MIME types as identifiers,
presumably), but realistically I'd say we keep the strict, opaque
string (that, we could mention, just happens to look like a MIME
type) in the tables and then say in the second paragraph of 3.3:

  Unless the incoming request had a DALI RESPONSEFORMAT parameter,
  the content-type header of the response MUST be
  application/x-votable+xml" with the "content" parameter set to
  "datalink", with the canonical form given in 3.1 strongly
  recommended.  Contrary to all other uses of the string given in
  3.1, clients wishing to evaluate the content type of the response
  must, however, perform a full parse of header value.  This is
  because this specification cannot and does not outlaw content types
  like
  "application/x-votable+xml; content=datalink;charset=iso-8859-1".

  If the incoming request had a DALI RESPONSEFORMAT parameter,
  content-type follows DALI's rules.

Incidentally, I'd like  to get rid of RESPONSEFORMAT, which only
further complicates all this.

Cheers,

         Markus