Implemntation hints Re: SODA gripes (1): The Big One

[François Bonnarel]

Hi all,
On 12/01/2016 15:25, Markus Demleitner wrote:
>> C ) With the current recommendations and the  SODA WD as it has been
>> proposed by the WD editor what can be implemented by data services. How IVOA
>> applications ( service clients) can manage with that and serve the end-user
>> needs ?
>>
>>      a ) You MUST build a SIAV2.0 service or an ObsTaP service dedicated to
>> your data cubes. Or both.
>>      b ) You MAY build a DataLink service providing resources attached to the
>> data cubes
>>      c ) you MUST build a SODA service providing cutout facilities for your
>> data cubes
>>      d ) the SODA service SHOULD be refered from the SIAV2.0 or ObsTAP
>> response via a service descriptor (with appropriate reference to the
>> publisher DID column) (case d1). Or it SHOULD be refered in the DataLink
>> resource response (if it exists) with appropriate reference to the iD column
>> in this response (case d2).
> Uh -- this looks scary.  Before anyone panics, can't we simply say:
>
> (1) You build an Obscore serive, if you want add SIAv2 glued on top.
> There's several usable TAP engines out there that you can use, so that's
> relatively easy to do.
>
> (2) For each dataset, you generate (either pre-generate or generate on
> the fly, which would be a datalink service) a little VOTable that
> describes access options.  This is what you let your Obscore table point
> to.
>
> (3) If you run SODA (e.g., for cutouts), this little VOTable also
> contains a description of how to operate it for the dataset in question.
>
> Much less scary, straightforward in implementation, regardless if you're
> a large or a small provider.
>
>
Yes, Markus, it is a good idea to write implementation notes in simple words

Cheers
François