[TAP] case sensitivity of query

[Douglas Tody]

On Thu, 5 Mar 2009, Gerard wrote:

> Dear Doug
>
> You made some statements that I have not seen discussed/decided yet:
>>
>> The SimDB case cited by Gerard is a different matter.  A data
>> model may specify case insensitive semantics if it wishes to.
> You seem to indicate that at least certain aspects of the following
> statement from p10 in TAP 0.4 have
> been decided on.
>
> [Arguably, the requirements above come into force because a
> service is registered as TAP. This opens the question as to
> inheritance of requirements when a service derived from TAP is
> registered in a different form. E.g., a service searching a catalogue
> image cubes could be defined as a TAP service with a specific
> data-model and a different form of registration. In this case it is not
> clear that ADQL query would still be mandatory. This point was
> discussed briefly at the October 2008 Interop but no conclusion
> was reached. -Ed.]
>
> Is that so?

No, I was not claiming that we had already decided how to do this.

The point was merely that in the SimDB type of use case where we
have a well-defined data model which is defined independently of the
implementation in a particular DBMS, it is probably the data model
which wants to be the basis for queries rather than the physical
DBMS table.

The solution then for a case like SimDB might be to have data
model based queries be case-insensitive, rather than try to make a
case-sensitive DBMS case-insensitive.


>>  UTYPEs for example are case insensitive.
> I must have missed this. Which definition of UTYPE is used here?

The first and most notable use of UTYPE I am aware of is in the DAL
interfaces, specifically SSA.  See section 2.11 ("UTYPEs and UCDs")
of the SSA specification:

     Both UTYPEs and UCDs are case-insensitive, and case should be
     ignored when comparing string values for equality.

The point being that we don't want to require a user or client
application to have to remember whether a UTYPE is (for example)
"DataID" or "DataId".  Nor, in the case of a well defined data model,
do we want to permit such tokens to refer to different things.

This is different than the case of a conventional DBMS containing
data tables, because in this case the DBMS both defines and consumes
its own metadata (table names etc.).  A data model is different as
it is defined externally, independent of implementation.

 	- Doug