SODA-1.0 - proposed erratum

[François Bonnarel]

Dear marco,

Very good for me

Thanks

François


Le 18/04/2019 à 18:22, Molinaro, Marco a écrit :
> Dear François, dear all,
> I tried to add your input in the rationale.
> Have a look whether it is fine and reflects your thoughts.
>
> I had also to modify the erratum content because I
> found out the wrong UCD was repeated another 3
> times in the text.
>
> If nothing else shows up I'll push this to TCG review tomorrow.
>
> Cheers
>      Marco
>
> Il giorno gio 18 apr 2019 alle ore 11:30 François Bonnarel 
> <francois.bonnarel at astro.unistra.fr> ha scritto:
>
>     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/f70d61f9/attachment-0001.html>