Cube Data Access Layer implementation note

[Laurent Michel]

Hello,

As this discussion seems to go around in circles, I'm going to try another attack angle.

All examples or discussion seen right now are based on the fact the SODA service are invoked from a Data link response.

I believe there is no requirement for this.
So it seems to me legal for DAL responses to have

    access_type=application/xml+votable;content=soda (Mime type to be validated)

Providing that way a direct access to a SODA service described ahead in the response.

If this is not true the  SODA functionality will enter the Datalink scope.

According to this, the SODA discussion should remain out of the scope of DataLink. However the distinction between these 2 
protocols will have to be clarified again and again, since lots of VO users are not comfortable at all with that.

My conclusion is that the discussion should remain focused on SODA (gripes) discussion and not polluted with Datalink 
considerations. In any case, a SODA service can be described in either in DAL responses or in Datalink responses.

Cheers
LM


Le 01/03/2016 16:04, François Bonnarel a écrit :
> 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
>>
>>

-- 
jesuischarlie

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34