Cube Data Access Layer implementation note

[François Bonnarel]

Dear Dal workers,
      According to Markus nomenclature this should be an answer "

(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.

     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 approiach of course.

             - The note assumes there is no "better" 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 tgo provide
             - the note assumes that DataLink, which is just a little bit of GLUE, as 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 methos of SIAV2. It shares the same syntax as SIAV2 and the same model as ObsTAP and SIAV2. We are 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
      

     

-- 
=====================================================================
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
---------------------------------------------------------------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cube-DAL.pdf
Type: video/x-fl
Size: 375707 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160301/0ea035e5/attachment-0001.bin>