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