The ref issue Re: SODA gripes (1): The Big One

[François Bonnarel]

The last one for today
On 12/01/2016 15:25, Markus Demleitner wrote:
>> email I tried to convince you that we allready have, without that "domain
>> metadata" feature a workable spec to fulfill the basic CSP spec.
>>     The solution is based on the inclusion of "ref" attributes in the service
>> descriptor PARAMETER elements for all the standard input PARAMETERS. ref to
>> the appropriate Obscore FIELD/PARAMETER or GROUP of FIELDS/PARAMETERS. This
>> can be done in the discovery service response, or in the response given by
>> the SODA service queried with the unique ID="dataset_id" constraint. Let's
>> see how it can work with examples in E and F.
> I'm tempted to remark that this kind of double referencing is pretty
> heavy stuff just a avoid what I've argued above isn't actually
> repetition in the first place, and that of course it doesn't solve
> operating SODA from datalink (or, equivalently, via SAMP).
>
> But the bigger problem with the proposed mechanism is that it breaks (or
> incompatibly overrides) what we have in datalink:
>
>    Although this version of DataLink only has one parameter (ID), using a
>    GROUP and providing the service parameter name allows this recipe
>    [parameters being filled from what its definition @ref's] to be used
>    with any service and (with the GROUP) with multi-parameter services.
>
> (http://ivoa.net/documents/DataLink/20150617/REC-DataLink-1.0-20150617.pdf,
> PDF page 21).  So, if SODA now proposed using @ref for pointing to
> relevant pieces of metadata, we'd have to explain when to immediately
> fill the parameter as per Datalink and when to use the ref'ed value as a
> hint as per SODA.  I don't like it.  At all.
Well, sure this is an issue for the solution I rapidly draw to show 
where i thought the connection between input PARAMS domain and ObsCore 
fields should be.
      - However, the feature you point out in DataLink is not yet used 
by current version of protocols except for ID, which is fully consistent 
with the solution I have drawn. So we could imagine modify slightly the 
DataLink text in next version, if we admit the "ref" mechanism.
     - we could also try to find another way to bind each PARAMETER 
definition with the relevant ObsCore columns (= model attributes). For 
example "reverse" refs.

What I really want to avoid is having the dataset limits with  the 
OBscore structure in one context and the same dataset limits with the 
<MIN><MAX> structure and absolutly no linkage between these two ways of 
providing the same concept. And what will happen  if people would occur 
to provide different values in these two different contexts ? Who would 
be right ? SO when we provide the Domain metadata we HAVE to find a way 
to provide this linkage.

Of course I am not speaking of a generic mechanism for custom services. 
I am speaking of cutouts required in the cube access context. that's 
what we have to provide NOW, and only that.

Have a good week end
Cheers
François
> Well, thanks for making it here.  Sorry for being so verbose, but I'm
> really, really worried we're messing up our one chance to have a widely
> adopted *and* implemented (on the client side, primarily) protocol for
> SODA: server-side operations on data.
>
> Cheers,
>
>                 Markus