[TAP] case sensitivity of query

Patrick Dowler patrick.dowler at nrc-cnrc.gc.ca
Mon Mar 2 10:28:35 PST 2009


(in response to a point in Gerard's email of 2009-02-19)

TAP 0.4 section 2.3.4 (QUERY parameter) says that the query string is case 
sensitive even though ADQL (and SQL92 before it) are not case-sensitive. This 
is worth airing as the reason for this may otherwise be lost.

It turns out that very late in the process of standardising ADQL 2.0 (at the 
Baltimore Interop, specifically) the point was raised that some existing 
databases have case-sensitive table and/or column names while ADQL is not 
case sensitive. Specifically, this means that the ADQL -> SQL translation 
performed by a TAP service with that sort of db backend would have to end up 
with the correct case for table/column/etc (e.g. names of things the caller 
discovers in the service metadata).

I see two possible options that would make things work:

1. The service exposes the correct case-sensitive names and TAP clients do not 
modify these names in any way. This is less extreme than what is stated in 
2.3.4 but in the same spirit (which is explained in that subsection). We 
could modify the text to say that the query is not case sensitive except in 
this one respect. 

2. The service has to accept a completely non-case query and if the backend db 
is case-sensitive the service has to map the table and column names from the 
metadata as necessary to make it work. This would get harder if the service 
really used case to distinguish things (like columns ra,dec,RA,DEC) but could 
still be done as long as the column names in the exposed metadata are unique. 
I don't know if anyone has/would make a database schema that way...

Note: It should be noted that the current metadata (TBD) plan is that the 
service exposes the fully-qualified table name (e.g. with as many of the 
catalog and schema specified as are needed for the query to be correct) and 
the client is expected to use the fully-qualified table names "as-is" and not 
to parse them to get at these constructs. This greatly simplifies the 
metadata (esp. the XML schema, I understand) and works fine. Thus, clients 
are already supposed to use use table names "as-is" and #1 above just extends 
it to include case and apply to column names.

Note: For TAP implementors where the DB is not case sensitive, neither of 
these effect you, but #1 marginally effects the client. 

Please comment asap.

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7



More information about the dal mailing list