DataLink 1.1 : step towards PR+RFC ????

[Mark Taylor]

Given that the proposed text changes are rather convoluted,
and that nobody is, as far as I know, actually using the currently
mandated content-type behaviour (evidence: Markus has been violating
it and nobody beside validation nerds have complained/noticed),
another possibility would just be to downgrade that MUST to a SHOULD:

  Unless the incoming request included a RESPONSEFORMAT parameter
  requesting a different format, the content-type header of the
  response SHOULD be ``application/x-votable+xml'' with the ``content''
  parameter set to ``datalink'', with the canonical form given in
  \ref{sec:mime} strongly recommended.

So: use the datalink content-type unless you've got a good reason not to
(as does Markus, and other service providers that use the same tricks
to render links tables in browsers, at least as long as browsers
won't apply XSLT to content-types marked with +xml).

This would technically be a breaking change from DL 1.0 to 1.1
(as would Markus's other proposed changes).  But given the likely impact
in practice of the change (none?) I think we could turn a blind eye.

Mark

On Mon, 9 Jan 2023, Markus Demleitner wrote:

> Dear DAL, Dear François,
> 
> On Fri, Jan 06, 2023 at 06:49:21PM +0100, BONNAREL FRANCOIS wrote:
> >        It would nice to have the RFC starting before next interop. I think
> > it's mature enough.
> > 
> >       Thoughts ?
> 
> Sure, let's go ahead.  Except...  there's one skeleton in the closet
> that recently came up again, and perhaps we can still somehow bury
> it before RFC.
> 
> The problem is the following text:
> 
>   Unless the incoming request included a RESPONSEFORMAT parameter
>   requesting a different format, 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
>   \ref{sec:mime} strongly recommended.
> 
> The purpose of this language is that clients can (relatively) easily
> work out that they are dealing with a Datalink document regardless of
> where they get it from (as long as it's http).  I think that's a good
> idea, although I'm not aware of a client that actually looks at
> content-type when retrieving things that could be datalink documents.
> 
> But at the same time this is blocking an important use case:
> Displaying datalink documents in the browser (Background:
> http://mail.ivoa.net/pipermail/dal/2021-April/008426.html and
> https://github.com/msdemlei/datalink-xslt).  When I wrote the XSLT
> for that in ~2016, I planned it as a temporary hack until there are
> good datalink clients, but now I think letting people open datalinks
> with the browser and getting something actually usable is a major use
> case in itself. 
> 
> The trouble with this: Web browsers will not apply the XSLT to
> documents with a media type of
> application/x-votable+xml;content=datalink.  I have to give them
> text/xml to start the whole magic.
> 
> I hence at the moment have the choice of violating the standard or
> breaking a use case important to me.  I weaseled around that first by
> inspecting user agent strings and only returning text/xml if the user
> agent looked as if I was dealing a web browser, praying nobody would
> notice.  But that broke rather quickly (I forget the details), and I
> switched to inspecting the accept header.  If I find a text/html in
> there, I return text/xml (yeah, it's that twisted), otherwise I'm
> compliant with the datalink spec.
> 
> But it's still a violation of the standard.  I had hoped programmatic
> use would not be impacted, but it turns out that, for instance, the
> JVMs earlier than 11 actually indicate acceptance of text/html, too.
> Sigh.
> 
> So... it's trouble, and I have not found any solution that doesn't
> make me cringe.  But I increasingly have the impression that ignoring
> the problem will only make matters worse.
> 
> The least horrible proposal I have would be to replace the text
> quoted above:
> 
>   When a datalink service returns a datalink VOTable (i.e., absent a
>   RESPONSEFORMAT parameter requesting something else), it MUST
>   indicate that in the response's content-type header.  When the
>   request's accept header includes ``application/x-votable+xml'',
>   then it MUST be ``application/x-votable+xml'' with the ``content''
>   parameter set to ``datalink'', with the canonical form given in
>   \ref{sec:mime} strongly recommended.  Otherwise, any legal VOTable
>   media type, including text/xml, is allowed.
> 
> That is: clients wishing to do dispatch based on the datalink media
> type must indicate that they accept VOTable.  It's a pretty safe bet
> that major browsers won't do that (and potential future VO-enabled
> browsers wouldn't need the XSLT, I'm sure).  And although HTTP
> content negotiation isn't as popular as it should be, I think it's
> implementationally not very intrusive.
> 
> The only alternative I could come up with would be to codify what I'm
> currently doing:
> 
>   Unless the incoming request included a RESPONSEFORMAT parameter
>   requesting a different format, and unless the user agent indicates
>   it will accept text/html, 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
>   \ref{sec:mime} strongly recommended.
> 
> We could then have a footnote explaining what the text/html exception
> is supposed to do.  The downside here is that it's really an ugly
> hack to return text/xml when accept has text/html, and there's too
> much library code that wantonly sticks text/html into accept behind
> the programmers' backs.
> 
> I think given the media type hasn't seen too much use so far anyway
> and when a client wants to use it, it would be new code anyway, I'd
> go for option one.
> 
> But if anyone had a less painful idea, that'd be even better.  Does
> anyone?
> 
>          -- Markus
> 

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