SODA-1.0 - proposed erratum

[François Bonnarel]

Hi all,

Thank you for preparing this erratum which I agree with of course.

About 3-factor semantics and SODA ID parameter I will make the following 
comment:

I thought 3-factor semantics was meanly thought for interpretation of 
custom parameters in service descriptors.

In the case of a parameter part of the standard like SODA ID, the 
definition of the parameter is unambiguous.

Maybe this could be reflected by the rationale ?

However a 3-factor description is still useful for  homegeneity and 
comparison to other parameters.

Best Regards

François
Le 17/04/2019 à 16:30, Molinaro, Marco a écrit :
> 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 
> <mailto: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 <http://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 <http://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/20190418/96b40f2d/attachment.html>