IVOA VOTable signature issue (DALI issue)

[Patrick Dowler]

I agree with this and have added clarification in DALI-1.1 (rev 3968).

Hope this gets in before Marco published the doc today :-)

Pat

On 24 April 2017 at 07:52, Markus Demleitner
<msdemlei at ari.uni-heidelberg.de> wrote:
> 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



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada