SODA-1.0 - proposed erratum

[Molinaro, Marco]

Hi Markus,
thank you for reviewing and commenting.
I modified the erratum accordingly.

Thanks also to James for promptly
acting on the validator.

Cheers
    Marco

Il giorno mer 17 apr 2019 alle ore 09:34 Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> ha scritto:

> Hi DAL,
>
> On Tue, Apr 16, 2019 at 08:23:38PM +0200, Molinaro, Marco wrote:
> [https://wiki.ivoa.net/twiki/bin/view/IVOA/SODA-1_0-Err-1]
> > @All: I don't think this erratum is complicated or controversial,
> > so I suggest you take a look at it and comment at your earlier
> > convenience so we can push it to TCG consideration quickly.
>
> The Erratum content I fully agree with, and as a co-author I'm
> somewhat embarrassed I missed this error; well, it was a fairly late
> addition (rev. 3961).  Still, I should've checked the diffs.  Watch
> me write in dust and ashes.
>
> I have, through both dust and ashes, a couple of more or less formal
> nits to pick:
>
> (a) the part with "thus achieving" in Erratum content is part of the
> rationale and should, I feel, go there.  I'd like the erratum a lot
> better if everything starting "thus achieving" went from "Erratum
> Content" and instead we'd append to "Rationale":
>
>   To remedy the situation, we propose here to use
>   "meta.id;meta.dataset" instead.  This achieves:
>
>   * typo amendment
>   * reference to a dataset rather than an organization
>   * using a UCD referring to an identifier rather than a resource locator
>   * keeping the identifier opaque as required by the specification
>
> (b) The impact assessment is overly optimistic.  This *would* be a
> major thing if anyone did 3-factor semantics on ID.  Which I think is
> not the case -- since there's not been much evolution on Datalink
> processing services before SODA, the SODA parameter names have, as it
> were, been reserved from the start, and so going by names exclusively
> is a fairly safe thing to do for them.
>
> Also, the argument that no SODA services have been registered is a
> weak one -- in general, there is no reason to register them, as
> nobody has yet offered a scenario that would make SODA discovery
> desirable; I certainly don't register any of mine.  Hence, we can't
> know how many SODA services are in place (I alone have ~10, and other
> DaCHS operators run at least another five).
>
> I'd hence propose to strike the text starting with "On the client
> side" and instead write:
>
>   On the client side, changing a UCD will break clients using 3-factor
>   semantics to find the parameter to pass the identifier in.
>   However, as ID is defined by both Datalink and SODA and no
>   competing definition ever existed, no known client actually uses
>   3-factor semantics to locate the ID parameter and instead just uses
>   the hard-coded name "ID".  Hence, to our knowledge the UCD changed
>   here is ignored by clients, and no breakage will occur.
>
>   The safety of changing this UCD is also plausible in view of the
>   fact that several data centers (e.g., GAVO's Heidelberg data
>   center; example here:
>
> http://dc.zah.uni-heidelberg.de/feros/q/sdl/dlmeta?ID=ivo%3A%2F%2Forg.gavo.dc%2F%7E%3Fferos%2Fdata%2Ff02891.fits
> )
>   have been successfully operating SODA services that used
>   meta.id;meta.main as a UCD for ID without interoperabilty issues.
>
> This latter observation perhaps can also count as an urgent call for
> validators...
>
>           -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20190417/95fc11e4/attachment.html>