SODA-1.0 - proposed erratum

[Markus Demleitner]

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