SODA-1.0 - proposed erratum

Molinaro, Marco marco.molinaro at inaf.it
Thu Apr 18 18:22:36 CEST 2019


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> 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/20190418/a6f7e38d/attachment.html>


More information about the dal mailing list