Cube Data Access Layer implementation note

[Markus Demleitner]

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.

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?

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