less required ADQL support [TAP-1.1]

François Bonnarel francois.bonnarel at astro.unistra.fr
Wed Sep 30 10:13:42 CEST 2015


Do you need a slot to discuss this in Sydney ?
Cheers
François
On 28/09/2015 20:13, Patrick Dowler wrote:
>
> In Sesto we discussed the possibility of TAP services providing tables 
> in non-SQL engines and how we could accommodate that. The couple of 
> things we agreed to explore was how to relax "ADQL required" to just 
> say that tap services must support ADQL queries of the TAP_SCHEMA tables.
>
> The goal/implication is that other tables could be provided which can 
> be queried by ADQL and/or some other languages... but the idea to open 
> up TAP to non-SQL type systems is to make it so they don't have to 
> support ADQL for all tables.
>
> So, without thinking too hard about *how* to do it, do we generally 
> agree that this is a suitable goal for TAP?
>
> ...
>
>
> Who am I kidding, you are going to think about *how* anyway...
>
>
> So, it's easy enough to make ADQL less required, but we also need a 
> mechanism to tell users/clients which LANG can be used:
>
> 1- this would be easy enough in TAP_SCHEMA
>
> 2- need to decide what to do with VOSI-tables (VODataService model)
>
> 3- at one extreme, you need to specify it for each table and 
> TAPRegExt. See the "TAPRegExt fine grained differences between tables" 
> email thread for a discussion of that...
>
> 4- at the other extreme, you could group all your ADQL tables under 
> one capability and all your LANG=NoSQL (eg) tables under another 
> capability (recall that TAP-1.1 defines standardID values per 
> capability and you will be able to have multiple async and/or multiple 
> sync capabilities - each with their own TAPRegExt metadata)... but 
> this isn't without implementation complications and it seems like a 
> pretty artificial way to do it to me
>
> - if these aren't enough, there are certain to be other complications
>
>


More information about the dal mailing list