less required ADQL support [TAP-1.1]

Patrick Dowler patrick.dowler at nrc-cnrc.gc.ca
Mon Sep 28 20:13:28 CEST 2015


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


-- 
Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)


More information about the dal mailing list