<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Hi Markus,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Thanks for the reminder - I've updated <a href="https://github.com/csiro-rds/sodalint" id="LPlnk557072">https://github.com/csiro-rds/sodalint</a> with the revised UCD and will make a release once the erratum is approved.</div>
<br>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Cheers,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
James.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div id="Signature">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div class="BodyFragment"><font size="2">
<div class="PlainText"></div>
</font></div>
</div>
</div>
<div id="appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> dal-bounces@ivoa.net <dal-bounces@ivoa.net> on behalf of Markus Demleitner <msdemlei@ari.uni-heidelberg.de><br>
<b>Sent:</b> Wednesday, 17 April 2019 5:34 PM<br>
<b>To:</b> dal@ivoa.net<br>
<b>Subject:</b> Re: SODA-1.0 - proposed erratum</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Hi DAL,<br>
<br>
On Tue, Apr 16, 2019 at 08:23:38PM +0200, Molinaro, Marco wrote:<br>
[<a href="https://wiki.ivoa.net/twiki/bin/view/IVOA/SODA-1_0-Err-1">https://wiki.ivoa.net/twiki/bin/view/IVOA/SODA-1_0-Err-1</a>]<br>
> @All: I don't think this erratum is complicated or controversial,<br>
> so I suggest you take a look at it and comment at your earlier<br>
> convenience so we can push it to TCG consideration quickly.<br>
<br>
The Erratum content I fully agree with, and as a co-author I'm<br>
somewhat embarrassed I missed this error; well, it was a fairly late<br>
addition (rev. 3961). Still, I should've checked the diffs. Watch<br>
me write in dust and ashes.<br>
<br>
I have, through both dust and ashes, a couple of more or less formal<br>
nits to pick:<br>
<br>
(a) the part with "thus achieving" in Erratum content is part of the<br>
rationale and should, I feel, go there. I'd like the erratum a lot<br>
better if everything starting "thus achieving" went from "Erratum<br>
Content" and instead we'd append to "Rationale":<br>
<br>
To remedy the situation, we propose here to use<br>
"meta.id;meta.dataset" instead. This achieves:<br>
<br>
* typo amendment<br>
* reference to a dataset rather than an organization<br>
* using a UCD referring to an identifier rather than a resource locator<br>
* keeping the identifier opaque as required by the specification<br>
<br>
(b) The impact assessment is overly optimistic. This *would* be a<br>
major thing if anyone did 3-factor semantics on ID. Which I think is<br>
not the case -- since there's not been much evolution on Datalink<br>
processing services before SODA, the SODA parameter names have, as it<br>
were, been reserved from the start, and so going by names exclusively<br>
is a fairly safe thing to do for them.<br>
<br>
Also, the argument that no SODA services have been registered is a<br>
weak one -- in general, there is no reason to register them, as<br>
nobody has yet offered a scenario that would make SODA discovery<br>
desirable; I certainly don't register any of mine. Hence, we can't<br>
know how many SODA services are in place (I alone have ~10, and other<br>
DaCHS operators run at least another five).<br>
<br>
I'd hence propose to strike the text starting with "On the client<br>
side" and instead write:<br>
<br>
On the client side, changing a UCD will break clients using 3-factor<br>
semantics to find the parameter to pass the identifier in.<br>
However, as ID is defined by both Datalink and SODA and no<br>
competing definition ever existed, no known client actually uses<br>
3-factor semantics to locate the ID parameter and instead just uses<br>
the hard-coded name "ID". Hence, to our knowledge the UCD changed<br>
here is ignored by clients, and no breakage will occur. <br>
<br>
The safety of changing this UCD is also plausible in view of the<br>
fact that several data centers (e.g., GAVO's Heidelberg data<br>
center; example here:<br>
<a href="http://dc.zah.uni-heidelberg.de/feros/q/sdl/dlmeta?ID=ivo%3A%2F%2Forg.gavo.dc%2F%7E%3Fferos%2Fdata%2Ff02891.fits">
http://dc.zah.uni-heidelberg.de/feros/q/sdl/dlmeta?ID=ivo%3A%2F%2Forg.gavo.dc%2F%7E%3Fferos%2Fdata%2Ff02891.fits</a>)<br>
have been successfully operating SODA services that used<br>
meta.id;meta.main as a UCD for ID without interoperabilty issues.<br>
<br>
This latter observation perhaps can also count as an urgent call for<br>
validators...<br>
<br>
-- Markus<br>
</div>
</span></font></div>
</body>
</html>