Cube Data Access Layer implementation note

[François Bonnarel]

There were too much typos in my email. Sorry about that, here is a fix.
On 01/03/2016 10:39, François Bonnarel wrote:
> Dear Dal workers,
>      According to Markus nomenclature this should be an answer to 
> Gripe " (3) In-DAL SODA descriptor optional, introductory text 
> (François)"
>
>     It is more or less the same topic but done in a very different way.
>
>     Facing the multiciplity of protocols and specs which are 
> independant but often work together and have to keep consistant, I 
> think it's better to have an independant implementation note which 
> explains how all these things fit together from Discovery to cutouts 
> and maybe more. Apparently nobody wanted this. So this an attempt to 
> show what it would look like for better understanding of my point.
>
>     The idea is that some people will have ObstAP and some will have 
> SIAV2. Some others wil have both.
>      Some will have DataLinks and not SODA (only retrieval). Some 
> other will have SODA and no DataLink because no other links available. 
> And some will have both
>
>      Some will keep their SIAP1 service and add a DatalInk or/and a 
> SODA layer.
>
>      I took as much as I could from Markus introductory text, but 
> refurbished it in a more generic way. The reason why he has been kept 
> as the first author although he is probably not happy with what I did. 
> But this is just a draft note, OK ?
>
>       There are differences of approach of course.
>
>             - The note assumes there is no "best way" to go from 
> discovery to  Links and to SODA. There are just ways more adapted to 
> use case so and so...
>             - The note assumes it may be unecessary to use DataLink to 
> go to SODA if there is no other links to provide.
>             - the note assumes that DataLink, which is just a little 
> bit of GLUE, has to stay as simple as possible and is not the better 
> place to write a lot of service/dataset metadata.
>                 - Last but not least: SODA is very close to ObsTAP and 
> to SIAV2. It should have been a simple method of SIAV2. It shares the 
> same syntax as SIAV2 and the same model as ObsTAP and SIAV2. We are 
> currently defining SODA:  now so we can decide that a SODA service has 
> the best knowledge of the dataset it is working on and about its 
> capabilities. This is autodescription which mlay use the Service 
> descriptor syntac?  We are not facing a custom legacy service where we 
> cannot do anything about the way it works and just have to describe 
> previously defined  parameters
>
> Cheers
> François
>
>