[TAP] case sensitivity of query
dtody at nrao.edu
Thu Mar 5 10:26:40 PST 2009
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
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.
More information about the dal