Cube Data Access Layer implementation note

[François Bonnarel]

Hi all,
     A partial answer:
On 01/03/2016 12:02, Markus Demleitner wrote:
>>              - Last but not least. SODA is very close to ObsTAP and
>>              to SIAV2. It should have been a simple methos of SIAV2.
> No, most definitely not.  All other protocols offering access to
> datasets require it as well, and historically, the first protocol it
> (or its predecessor, which still is very close to it) was used
> together with was SSA.
SSA has it own embedded AccessData Functionality. And as for the 
"GetData" service you have been developping at GAVO 
(http://docs.g-vo.org/talks/2012-urbana-ssaevo.pdf and 
http://www.g-vo.org/pmwiki/uploads/Documentation/splat_interop_HD.pdf), 
which offer more to the users,  It is allready fully integrable in the 
VO as a CUSTOM SERVICE with help of the standard DataLink 
functionalities. But Having GetData (or its successor) as the standard 
for cubes is another story. See below.

SODA functionality has been "extracted" from SIAV2 initial project for 
one single reason : The same functionality had to be accessible frm 
DIAV2  or from ObtAP query phases indifferently. But we cannot do as if 
there is no strong link in the conception and also for implementers.
>
>>              It shares the same syntax as SIAV2 and the same model
>>              as ObsTAP and SIAV2. We are defining SODA now so we can
> No, it does not, at least as far as the model is concerned.  SODA, to
> be useful, needs to be model-free[1],

Ah !!! This is the point where we really differ, Markus. Currently SODA 
doesn't have to be model-free it has to be adapted to ND-Cubes and we 
have a simple model for that which is Obscore and we will have a full 
one, CubeDM (in a near future because it's allreday in good shape)
I think it would be a pity not to benefit from the clean description the 
data model provides for cubes. SODA standard parameetrs are really 
funded on the model so far.
The mandate we have as DAL WG  is to fulfill the CSP priorities for 
cubes, and allow archives who have cubes to provide simple cutout 
facilities. We don't have to disperse into a generic and then more 
complex thing.

See my following mail later today for a proposal to go forward.

> which is why it can easily work
> for all of SIAv1, SSA, SIAv2, ObsCore, and future protocols we will
> fairly certainly define -- that (and the fact we will not want to
> touch SODA itself every time we have a new data type in the VO) is
> what the three-factor semantics is all about.
If you have standard parameters described in the spec you don't actually 
need the 3 factor semantics for those. But it is nice and is an 
additional "gift" to have it for building more clever clients, I agree.
Accessing SODA from SOIAV1, SSA or over non standard dataset discovery 
pathes is also and additional "gift", we have to be carefull to stay as 
open as possible, yes.

Cheers
François