Datalink service descriptor usage

Marco Molinaro molinaro at
Sun Feb 4 08:31:52 CET 2018

Hi Mark, all,

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

> 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

> 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

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).


* - happy you sent this email 'cause you forced him
into a deeper look in Datalnk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the dal mailing list