Datalink service descriptor usage

[Markus Demleitner]

Hi Mark,

On Fri, Feb 02, 2018 at 11:33:44AM +0000, Mark Taylor wrote:
> 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'd consider it odd and probably unfortunate if in a links reponse
the same service descriptor applied to more than one row.  The reason
is that different datasets almost always will have different
properties (like, footprints).  Hence, as least some of the parameter
metadata (which really *should* include valid limits/options) will be
different between datasets.  Hence, they can't really share service
definitions if done properly.

See, for instance,

http://dc.zah.uni-heidelberg.de/califa/q3/dl/dlmeta?ID=ivo://org.gavo.dc/~?califa/datadr3/COMB/ARP220.COMB.rscube.fits&ID=ivo://org.gavo.dc/~?califa/datadr3/COMB/IC1078.COMB.rscube.fits

(note that the stylesheet you'll get when you open this in a browser
doesn't really cater for the case of multiple datasets (yet), so just
fetch the XML; also, kindly don't ask where the forms of the RESOURCE
IDs come from).

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

Well, I'd put it this way:  in the "VOTable shortcut", you should go from
the service descriptor to the table, in the regular links response
case, you should go from the datalink rows to the descriptor.

Anyway, the intention was certainly that Datalink documents can be
parsed as VOTables but should really be treated specially if at all
possible, in particular as regards semantics and the service blocks.
And *if* there's ever rows for multiple datasets, I'm pretty sure
some strong grouping should be implied to pull them apart.

         -- Markus