IVOA VOTable signature issue (DALI issue)

[Markus Demleitner]

Dear DAL,

sorry for bringing this up again (but since it's now clearly DAL,
I've taken apps from the distribution at least).

I wanted to implement the following:

On Thu, Mar 30, 2017 at 11:57:19AM +0100, Mark Taylor wrote:
> Marco,
> 
> On Mon, 27 Mar 2017, Marco Molinaro wrote:
> 
> > that, for now at least something like:
> > 
> > <info name="STANDARD_ID" value="ivo://ivoa.net/TAP"/>
> > 
> > may be ok.
> > 
> > Now, while looking at DALI-1.1, I realized that it's already there
> > (§4.4.3) and it's there since DALI-1.0.
> 
> Good catch!  And apologies that (as a listed DALI author) I didn't
> realise that was in place.

And sure enough, the devil's in the details.

The example in DALI actually is 

  <RESOURCE type="results">
  <INFO name="standardID" value="ivo://ivoa.net/TAP"/>

-- which for TAP 1.0 is ok.  With newer protocols, this requires a
bit more thought, though.

Now consider SIAP version 2.  The standard ID of the respective
standard is ivo://ivoa.net/std/sia.  The standard id of the
*capability* that produces a file actually is (probably) 
ivo://ivoa.net/std/sia#query-2.0 -- that's what's used for discovery.

In this particular case, that thing, at least with the version, is
probably what Pierre wants; a version 1 response is substantially
different.

On the other hand, TAP, perhaps only in version 2 as well, will have
separate capabilities with standard ids *like*

ivo://ivoa.net/std/tap#sync-2.0 
ivo://ivoa.net/std/tap#async-2.0 (but see below on "tap" in there)

-- there are again discovery use cases that strongly suggest a
structure like this.

For a VOTable signature, however, that's probably not so useful --
ignoring the questionable value of knowing that something originated
from a TAP service, a VOTable consumer most certainly shouldn't be
bothered with the information whether a result was obtained using UWS
or just plain HTTP.

I believe this latter pattern is typical: if at all, you want to
figure out if it's "somehow a spectrum list (SSAP)" or "somehow a
source list (SCS)".  And we actually got it wrong in SIAP.  If we
push a standard to a new major version, I believe we should have a
new standards record, too; from a machine perspective, the new
protocol is unrelated to the previous standard.  So, let's not base
our mechanism on that flawed precedent.

After this, I believe DALI should say (if it's too late for adding it
now, it's ok to defer this to an erratum) in the table on p. 29 for
standardID: "IVOA standardID for the service specification.[1]" And
the footnote: "[1] This is usually *not* the standardID for the
capability that generated the VOTable (something like
ivo://ivoa.net/std/tap#sync-1.1) but rather a reference to the
StandardsRegExt record (something like ivo://ivoa.net/tap)".



And while playing around with this I came to the conclusing that the
whole proposal is indeed a fairly flimsy hack for something that
should eventually be done through data model annotation, namely
SourceList (that lets clients work out actual objects on the sky from
the table) and Obscore (that lets clients work out that there are
multiple datasets described in the table and perhaps what their
nature is).  The latter already works fine for SIAv2, so the trouble
discussed above can almost immediately be worked around (of course,
proper annotation of the obscore table would even be better, but
obscore utypes should to until then).

But let's not hold our breath.  I still think INFO[@name=standardID]
is a useful hack, and it will appear in stuff going out from
dc.g-vo.org real soon now (other DaCHS sites hopefully starting
July-ish).


       -- Markus