<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi all,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have two items on my TODO list for DataLink:</div><div class="gmail_default" style="font-size:small">1. clarify multiple #this -- components vs alternatives (from a discussion Markus and I had during the interop)</div><div class="gmail_default" style="font-size:small">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)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I think I can get to this later this week or early next.<br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 9 Jan 2023 at 08:38, BONNAREL FRANCOIS <<a href="mailto:francois.bonnarel@astro.unistra.fr">francois.bonnarel@astro.unistra.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hum,<br>
Thinking about it, I tend to agree with Markus option one because <br>
depends of VO tool developpers in that case.<br>
Anyway I create a new github issue with this discussion<br>
Cheers<br>
François<br>
Le 09/01/2023 à 11:35, Mark Taylor a écrit :<br>
> Given that the proposed text changes are rather convoluted,<br>
> and that nobody is, as far as I know, actually using the currently<br>
> mandated content-type behaviour (evidence: Markus has been violating<br>
> it and nobody beside validation nerds have complained/noticed),<br>
> another possibility would just be to downgrade that MUST to a SHOULD:<br>
><br>
> Unless the incoming request included a RESPONSEFORMAT parameter<br>
> requesting a different format, the content-type header of the<br>
> response SHOULD be ``application/x-votable+xml'' with the ``content''<br>
> parameter set to ``datalink'', with the canonical form given in<br>
> \ref{sec:mime} strongly recommended.<br>
><br>
> So: use the datalink content-type unless you've got a good reason not to<br>
> (as does Markus, and other service providers that use the same tricks<br>
> to render links tables in browsers, at least as long as browsers<br>
> won't apply XSLT to content-types marked with +xml).<br>
><br>
> This would technically be a breaking change from DL 1.0 to 1.1<br>
> (as would Markus's other proposed changes). But given the likely impact<br>
> in practice of the change (none?) I think we could turn a blind eye.<br>
><br>
> Mark<br>
><br>
> On Mon, 9 Jan 2023, Markus Demleitner wrote:<br>
><br>
>> Dear DAL, Dear François,<br>
>><br>
>> On Fri, Jan 06, 2023 at 06:49:21PM +0100, BONNAREL FRANCOIS wrote:<br>
>>> It would nice to have the RFC starting before next interop. I think<br>
>>> it's mature enough.<br>
>>><br>
>>> Thoughts ?<br>
>> Sure, let's go ahead. Except... there's one skeleton in the closet<br>
>> that recently came up again, and perhaps we can still somehow bury<br>
>> it before RFC.<br>
>><br>
>> The problem is the following text:<br>
>><br>
>> Unless the incoming request included a RESPONSEFORMAT parameter<br>
>> requesting a different format, the content-type header of the<br>
>> response MUST be ``application/x-votable+xml'' with the ``content''<br>
>> parameter set to ``datalink'', with the canonical form given in<br>
>> \ref{sec:mime} strongly recommended.<br>
>><br>
>> The purpose of this language is that clients can (relatively) easily<br>
>> work out that they are dealing with a Datalink document regardless of<br>
>> where they get it from (as long as it's http). I think that's a good<br>
>> idea, although I'm not aware of a client that actually looks at<br>
>> content-type when retrieving things that could be datalink documents.<br>
>><br>
>> But at the same time this is blocking an important use case:<br>
>> Displaying datalink documents in the browser (Background:<br>
>> <a href="http://mail.ivoa.net/pipermail/dal/2021-April/008426.html" rel="noreferrer" target="_blank">http://mail.ivoa.net/pipermail/dal/2021-April/008426.html</a> and<br>
>> <a href="https://github.com/msdemlei/datalink-xslt" rel="noreferrer" target="_blank">https://github.com/msdemlei/datalink-xslt</a>). When I wrote the XSLT<br>
>> for that in ~2016, I planned it as a temporary hack until there are<br>
>> good datalink clients, but now I think letting people open datalinks<br>
>> with the browser and getting something actually usable is a major use<br>
>> case in itself.<br>
>><br>
>> The trouble with this: Web browsers will not apply the XSLT to<br>
>> documents with a media type of<br>
>> application/x-votable+xml;content=datalink. I have to give them<br>
>> text/xml to start the whole magic.<br>
>><br>
>> I hence at the moment have the choice of violating the standard or<br>
>> breaking a use case important to me. I weaseled around that first by<br>
>> inspecting user agent strings and only returning text/xml if the user<br>
>> agent looked as if I was dealing a web browser, praying nobody would<br>
>> notice. But that broke rather quickly (I forget the details), and I<br>
>> switched to inspecting the accept header. If I find a text/html in<br>
>> there, I return text/xml (yeah, it's that twisted), otherwise I'm<br>
>> compliant with the datalink spec.<br>
>><br>
>> But it's still a violation of the standard. I had hoped programmatic<br>
>> use would not be impacted, but it turns out that, for instance, the<br>
>> JVMs earlier than 11 actually indicate acceptance of text/html, too.<br>
>> Sigh.<br>
>><br>
>> So... it's trouble, and I have not found any solution that doesn't<br>
>> make me cringe. But I increasingly have the impression that ignoring<br>
>> the problem will only make matters worse.<br>
>><br>
>> The least horrible proposal I have would be to replace the text<br>
>> quoted above:<br>
>><br>
>> When a datalink service returns a datalink VOTable (i.e., absent a<br>
>> RESPONSEFORMAT parameter requesting something else), it MUST<br>
>> indicate that in the response's content-type header. When the<br>
>> request's accept header includes ``application/x-votable+xml'',<br>
>> then it MUST be ``application/x-votable+xml'' with the ``content''<br>
>> parameter set to ``datalink'', with the canonical form given in<br>
>> \ref{sec:mime} strongly recommended. Otherwise, any legal VOTable<br>
>> media type, including text/xml, is allowed.<br>
>><br>
>> That is: clients wishing to do dispatch based on the datalink media<br>
>> type must indicate that they accept VOTable. It's a pretty safe bet<br>
>> that major browsers won't do that (and potential future VO-enabled<br>
>> browsers wouldn't need the XSLT, I'm sure). And although HTTP<br>
>> content negotiation isn't as popular as it should be, I think it's<br>
>> implementationally not very intrusive.<br>
>><br>
>> The only alternative I could come up with would be to codify what I'm<br>
>> currently doing:<br>
>><br>
>> Unless the incoming request included a RESPONSEFORMAT parameter<br>
>> requesting a different format, and unless the user agent indicates<br>
>> it will accept text/html, the content-type header of the response<br>
>> MUST be ``application/x-votable+xml'' with the ``content''<br>
>> parameter set to ``datalink'', with the canonical form given in<br>
>> \ref{sec:mime} strongly recommended.<br>
>><br>
>> We could then have a footnote explaining what the text/html exception<br>
>> is supposed to do. The downside here is that it's really an ugly<br>
>> hack to return text/xml when accept has text/html, and there's too<br>
>> much library code that wantonly sticks text/html into accept behind<br>
>> the programmers' backs.<br>
>><br>
>> I think given the media type hasn't seen too much use so far anyway<br>
>> and when a client wants to use it, it would be new code anyway, I'd<br>
>> go for option one.<br>
>><br>
>> But if anyone had a less painful idea, that'd be even better. Does<br>
>> anyone?<br>
>><br>
>> -- Markus<br>
>><br>
> --<br>
> Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
> <a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a> <a href="http://www.star.bristol.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bristol.ac.uk/~mbt/</a><br>
<br>
<br>
</blockquote></div>