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

Mon Jan 9 21:57:50 CET 2023

Hi all,

I have two items on my TODO list for DataLink:
1. clarify multiple #this -- components vs alternatives (from a discussion
Markus and I had during the interop)
2. DataLink: summary from  FB, review changes, PR (which iirc means I was
going to compare Francois' summary of changes with the doc changes and the
changelog, I also said I'd list somewhere the changes that we have actually
implemented at CADC and iirc release 1 or 2 that have been sitting on the
back burner... and then we'd be ready for RFC)

I think I can get to this later this week or early next.
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada

On Mon, 9 Jan 2023 at 08:38, BONNAREL FRANCOIS <
francois.bonnarel at astro.unistra.fr> wrote:

> Hum,
>     Thinking about it, I tend to agree with Markus option one because
> depends of VO tool developpers in that case.
>     Anyway I create a new github issue with this discussion
> Cheers
> François
> Le 09/01/2023 à 11:35, Mark Taylor a écrit :
> > 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/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20230109/f2830a91/attachment-0001.htm>