Datalink feedback IV

[Mark Taylor]

Markus,

I see, there were more dragons here than I appreciated.
Your suggested text is fine by me.

Mark

On Mon, 31 Mar 2014, Markus Demleitner wrote:

> 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
> 
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/