[TAP] case sensitivity of query

[Doug Tody]

On Mon, 2 Mar 2009, Patrick Dowler wrote:

> (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.

There are two different issues here: whether the QUERY string (string
value of the QUERY parameter) is case sensitive, and whether the
query *processing* performed by the service is case sensitive.

The query processing can be quite complex with different aspects, e.g.
as Tom detailed in his posting.  For example the ADQL language per se
is case insensitive, but the data being manipulated (string literals,
table and column names) may or may not be.  Whether or not table and
column names are case sensitive will depend upon the DBMS.  It would
seem though that string literals passed as data must be allowed to
be case sensitive.

Hence the QUERY string itself (string value of the QUERY parameter,
regardless of the semantics of its content) wants to be case sensitive
as currently stated in the TAP spec.  This is doubly the case since
LANG is allowed to reference unspecified query processing languages
which may or may not be case sensitive.

Whether or not the case of schema data (table and column names etc)
is required to be preserved by the client is arguable, but I feel
that it is way too complex to require the ADQL processing to fully
parse the query and attempt to automatically resolve table metadata.
Depending upon the sophistication of the service implementation and
whether adequate metadata is provided at the DBMS level this may or
may not be feasible.  What if the data provider is using some existing
service framework we provide, but does not bother to provide sufficient
metadata to enable such a clever translation?

It is simpler, safer, and more efficient to require that the client
merely preserve case for DBMS data such as table and column names,
and leave it up to the DBMS to report an error if it is unable to
process the query.  If the DBMS is case insensitive or the service
implementation wants to provide case insensitive execution then the
requirement may be relaxed for that service instance.

The SimDB case cited by Gerard is a different matter.  A data model
may specify case insensitive semantics if it wishes to.  UTYPEs for
example are case insensitive.  The TAP_SCHEMA is also case insensitive
(the schema itself, not the data it returns).  But the data stored
within a DBMS is arbitrary and in general may be case sensitive.

 	- Doug