Datalink service descriptor usage

[Marco Molinaro]

Hi Mark, all,

2018-02-02 12:33 GMT+01:00 Mark Taylor <m.b.taylor at bristol.ac.uk>:

> Dear DAL,
>
> I have another question about the DataLink standard.
>

Note: I don't consider myself a Datalink expert.
I'm taking your mail as a chance to climb that
expertise.


> Section 4 of the DataLink document describes Service Descriptors.
> These are RESOURCE elements in VOTable documents containing
> information about external services that can be invoked in
> a way that is relevant to the data in a results table contained
> within the same VOTable document.
>
> As I understand it, there are two separate ways these service
> descriptors can be used.
>
>   1. A {links}-response table (as described in DataLink section 3)
>      may refer to a specific Service Descriptor by giving its ID
>      in the service_def column.
>
>   2. Any VOTable is allowed to include Service Descriptor resources,
>      as made explicit in paragraphs 2 and 3 of DataLink section 4.
>      Such service descriptors will presumably have at least some
>      input parameters that take their values from the results table.
>
> In case 2, the service descriptor effectively defines a different
> (full or partial) service invocation for every row of the results table.
> In case 1 however, such invocations are only defined for those rows
> in which the service_def column names the descriptor in question.
>

I agree, but I would say that your description of case 2
may fail if no DatasetID is set in a row. But that's probably
a borderline case.

My idea of datalink is simply that of a subsequent step to
initial data discovery, whatever the discovery protocol used.

The distinction between 1 and 2 being only on where the
service descriptor adhoc:service sits: directly on the
results of discovery, in a further (multi)-access enabling
document.

So client code that handles service descriptors generically,
> by offering service invocations per-row for each service
> desriptor, cannot be used for links-response tables.
>

I agree in the sense that links-responses are a different
(second) set of dataset access metadata (otherwise
a URL would suffice in the first discovery response.


> It must be replaced instead by code which offers invocations
> only for those rows with the relevant service_def values.
> Such clients must therefore be able to identify whether a
> given table is or is not a links-response table and behave
> appropriately.
>
> Have I got that right?
>

I think so, but see the note at the top.
You can prepare a client dialog/form only where a
service definition is available.
Otherwise a URL follow up should suffice (but there
the MIME-type topic gets in).

Cheers
      Marco*

* - happy you sent this email 'cause you forced him
into a deeper look in Datalnk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180204/5cf5b80f/attachment.html>