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