TAP information schema

[Gretchen Greene]

Patrick,  

Thanks for pointing out the requirements for fully qualified table names,
it appears to be a case of
oversimplification is the early presented usage.

I really am not clear on what your summary means in terms of how a client
will access the tap services.
I thought ADQL was to provide the query language specification for accessing
tap services,  but maybe I'm
missing something in your point of accessing them through registry
protocols.

A VORegistry persistence of service table names and columns are
theoretically available via the standard registry interface.  This interface
can be queried as keyword or adql, thus I do not see how we are escaping the
issue of adql not handling 
full db table schema name specifications unless we limit the query level.   

-Gretchen




-----Original Message-----
From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf Of Patrick
Dowler
Sent: Friday, October 12, 2007 1:03 PM
To: Undisclosed.Recipients :
Cc: dal at ivoa.net
Subject: Re: TAP information schema


It isn't really all that dire :)

The crux is that to use TAP the user needs to know the table name 
unambiguously; in the db this is the fully qualified table name (FQTN for 
short), which is $catalog.$schema.$table

For the purposes of TAP 1.0, it would be sufficient to say that the
VOResource 
metadata about tables an columns (which is what one needs for discovery 
anyway) has to specify unique, unambiguous table names.

What we should be careful about is to make sure that we do not include any 
semantic meaning in such FQTNs - just say they have to be unique within the 
service and leave it at that. In MySQL there is one catalog, so FQTNs can be

reduced to $schema.$table in that case. In general one always has a default 
catalog they are connected to, so any TAP service which keeps all the
content 
in one catalog could do the same... others that expose multiple catalogs via

a single TAP (eg upload VOTables to a VOSpace and they are available in  the

service) might want to do that or they might want to use a separate catalog;

that is defintely what I would do. Still others might have historically used

the catalog as the namespace (we do that in our sybase servers, eg), so
there 
we would use FQTNs like $catalog..$table or $catalog.dbo.$table.

Summary: I think we could get away with just having 1+ opaque unique table 
names in the VOResource metadata and TAP implementors can decide if they
want 
to put something arbitrary and map it to their DB or they can just put their

real FQTN in there and not have to process the ADQL at all. We just have to 
make sure this thing has no specific meaning (well, people will see and
parse 
it and make assumptions anyway, that's unavoidable) that ties us down later.

my 2c,

Pat

On 2007-10-12 01:08, Tony Linde wrote:
> I thought TAP was a mechanism for sending ADQL through to registered
> services. The various posts here sound like trying to solve perceived
> problems with ADQL and Registry in TAP: that IMHO is the wrong way round.
> TAP spec should simply be used to push ADQL to a service then you get the
> changes you want into ADQL and the Registry and TAP still works. If ADQL
is
> changed so that it supports qualified table names then, and only then,
> should you update TAP to support the new spec, not try to predict what
ADQL
> might look like in the future. If OTOH you are saying no-one can possibly
> use ADQL as it stands and there is no point producing TAP based on the
> current ADQL spec then you should get ADQL changed first, but I really do
> not think that is the case.

-- 

Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)