SODA gripes (3): Explanatory introduction

[François Bonnarel]

Hi Markus, all;
On 11/02/2016 08:06, Markus Demleitner wrote:
> Hi,
>
> On Wed, Feb 10, 2016 at 05:48:24PM +0100, François Bonnarel wrote:
>>       Sorry for not commenting this email earlier.
>>       I also think Markus did a very usefull job, with that introduction.
>>       I thought something like that was to be done but I would have opted for
>> an implementation Note of ObsTAP_or_SIAV2+DataLink+SODA.
>>       Because obviously this describes how these protocols work together to
>> combine data discovery to access data facilities, more than SODA alone in
>> itself. Next version of ObsTAP, SIAV2 and DataLink could refer to the same
>> note.
> Well, most people interested in the VO moan that there's so terribly
> many different documents to read (there once was an impressive
> collection sent around by Tom McGlynn on what he needed to parse to
> implement TAP).  We should not lightly increase that number.
I think I gave my arguments to James this morning. The implementation 
note coulde be the best tool for implementers to make their way among 
the various versions of the various protocols.
> In that vein, I still feel SODA shouldn't have been ripped out of
> Datalink in the first place.  It's been part the proposal of the
> service descriptor part of Datalink from the start, and as we have
> seen it cannot really be understood without it.
>
> While that ship has sailed (or has it?  Couldn't Datalink 1.1
> re-absorb SODA?), let's not make matters worse by further splitting
> up the material.
If we do that, I think it should also raebsorb ObsTap and SIAV2. Cutout 
facilities were originally designed as parat of the "simple protocols". 
As allready said they share the same model (Obscore). They were 
separated because we now have too different pathes to discovery with 
ObsTAP/ADQL and SIAV2/Parameters. I don't think we want to merge these 
protocol services back
Moreover DataLink has to be rather independant because linking to 
services like SODA is only one among ten ore more of the possible links 
we have in our datalinks semantics table.  DataLink tables may also link 
you to no SODA endpoint at all in some legacy  service usecases.  So I 
think it is mixing too much different things to extend the role of the 
DataLink document.
>   Also, we're talking about two or three pages, and
> they'd be required reading for SODA anyhow.
>
> Our implementors will be grateful.
>
>>        On the content itself of this section/note , I would like
>>                 -   to propose a few changes on some details.
>>                 -  add a subsection on SODA self-description (which is
>> allraedy in the spec. Editor's version)
> Are you referring to 2.6.3 here?
I was not joking. Services like SODA are the best placed to describe 
themselves in association with metadata for a single dataset which they 
know.
Tommorrow we may imagine to use Links towards a new sort of service 
which you can query via loading json files insted of parameters. How 
will we describe this (or other completly different query methods) in 
the DataLink document ? It's better to say in this document that these 
services are autodescriptive.

Cheers
François
>   If so: Why define a separate
> endpoint (capability?) with essentially the same content as a
> datalink document?  Even if you have no additional datalinks, telling
> people to stereotypically prepend a one-line (or perhaps even empty)
> datalink results table would seem much more economical to me.
>
> Cheers,
>
>             Markus

>