Cube Data Access Layer implementation note

[François Bonnarel]

Hi again,

On 03/03/2016 09:03, Markus Demleitner wrote:
> Dear Laurent,
>
> On Wed, Mar 02, 2016 at 05:20:37PM +0100, Laurent Michel wrote:
>> Hi Markus
>>
>> Let's "try again with an explanation":
>>
>> Imagine the following fields in your DAL response (SIAV2 e.g.)
>>
>>   access_type=application/xml+votable;content=soda
>>   access_url=http://my.soda?ID=xyz
>>
>> These 2 values are enough to run SODA with the common parameters (POS,TIME..).
>> The relevant parameter ranges can likely be found within the
>> current VOTable. No need to any explicit reference to any DM for
>> this.
>> If you want to refine the SODA description, just run
>> http://my.soda?ID=xyz and get a classical service descriptor.
> Ah -- but note that the difference between this and a normal datalink
> endpoint is very small.  This SODA endpoint would return documents of
> the structure
>
> <VOTABLE>
>    <RESOURCE type="meta" utype="adhoc:service" ID="svc">
>      [Service descriptor content]
>    </RESOURCE>
> </VOTABLE>
>
> whereas if we just re-used datalink as-is, the structure would be:
>
> <VOTABLE>
>    <RESOURCE type="results">
>      [Data links]
>    </RESOURCE>
>    <RESOURCE type="meta" utype="adhoc:service" ID="svc">
>      [Service descriptor content]
>    </RESOURCE>
> </VOTABLE>
>
> If a service really does not have any data links, the [Data links]
> thing above is very stereotypical; it's just a link with the
> dataset's pubdid, a #proc semantics and a pointer to svc.  With a bit
> of organisation, you could have the entire results RESOURCE in a
> fixed string.
>
>> To me, the gain is 2 folds: 1) No need operate a Datalink service to run a
>> SODA service 2) Applying this scheme to DataLink response could (or not - up
>> to you) save the duplication of the SODA service descriptor for each link.
>> The (low) cost: pushing the parameter description from the Datalink service to this new and simple SODA capability .
> So, ad (1): Saving the stereotypical results RESOURCE on the service
> side seems a neglible benefit to me, in particular considering the
> cost that we'd still have to define a new service interface (which
> furthermore happens to be almost identical to datalink, except
> perhaps that ID would be fixed to single-value from the start), a new
> media type, and that the clients have to deal with two different
> but very similar formats.
I support Laurent's proposal which recall me what we had in SIAV1.0 and 
SSA under the "FORMAT=METADATA" query. This was answering by describing 
the input parameters of the service in a way which looks a lot  like a 
modern service descriptor (apart some archaisms)

The main limitation was that format = metadata could not be attached to 
a specific dataset and provide metadata valid only for it.
> Ad (2): I cannot see a benefit in taking the service blocks out of
> the datalink response proper -- you have to generate them in your
> scheme, too; and why should it be preferable to serve them from an
> extra endpoint than to just embed them into the main datalink
> response?
The benefit will be to enlight the fact that DataLink is not done only 
for exposing SODA services or dynamical standard services but also 
custom services and static links. service description the DataLink 
response is fine for custom services wher we have absolutly no control 
on the way they can answer to an autodescription query. In the case of 
standard services we currently define like we do for SODA, we can still 
fine tune this in the SODA service itself.

DataLink Table is a little bit of "glue" (with little description of the 
links) between datasets and resources. "cutout" is only ONE among  
SIXTEEN semantical possibilities on the nature of the links. See 
http://www.ivoa.net/rdf/datalink/core/2014-10-30/datalink-core-2014-10-30.html

We should avoid too much overloading of DataLink responses by cutout details

Cheers
François
>
> I totally give you it is unfortunate that the datalink interface
> leads clients to expect they can request multiple IDs, and you'd have
> my vote to remove that any day.  But as Pat says, even with the
> current spec you're allowed to discard extra IDs (at the expense of
> having to give an overflow indicator, which may be a bit annoying but
> is not dramatic).  Plus I expect clients won't use the multi-ID thing
> anyway.
>
> And the multiple service blocks aren't horrible on the serice side
> anyway.  On the client side -- well, that's another matter, but I've
> not formed an opinion there yet.
>
> So -- I'd still maintain we shouldn't increase the number of
> endpoints.  And rather write clients.
>
> On that very matter of clients (or makeshift clients), I mention in
> passing that I've extended my XSLT-to-datalink stylesheet to do basic
> UI generation from service descriptors, including intervals.  You can
> see the current state in action from the dlmeta links on
>
> http://dc.zah.uni-heidelberg.de/califa/q2/cubesearch/form?__nevow_form__=genForm&_DBOPTIONS_ORDER=&MAXREC=100&_FORMAT=HTML&submit=Go
>
> (and I'm sure you can break the xtype=interval params in the current
> implementation, which at this point are at the proof-of-concept
> level; also, the port from atomic to interval parameters isn't quite
> done everywhere yet).
>
> Implementors are welcome to use (and improve!) the stylesheet at
>
> https://github.com/msdemlei/datalink-xslt.git
>
> My next plan with this would be to use three-factor-semantics to
> provide a cutout over a sky image when RA and DEC are present (if
> someone has some javascript for that already, I'd be highly
> interested) and to put in sliders where appropriate when the client
> knows enough javascript to have "two-nosed" (lower and upper limit)
> sliders with editable input boxes.  Again, contributions are highly
> welcome -- I'm sure this kind of thing has been written many times
> before.
>
> Cheers,
>
>             Markus


-- 
=====================================================================
François   Bonnarel           Observatoire Astronomique de Strasbourg
CDS (Centre de données        UMR 7550 CNRS / Université de Strasbourg
astronomiques de Strasbourg)  11, rue de l'Université
                               F--67000 Strasbourg (France)
     
Tel: +33-(0)3 68 85 24 11     WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 68 85 24 25     E-mail: francois.bonnarel at astro.unistra.fr
---------------------------------------------------------------------