Subject: re- TSORTKEY convention

From: francois at SIMBAD.u-strasbg.fr (Francois Ochsenbein)
Date: Thu, 8 Dec 94 21:46:13 +0100

I would like to see more comments about the TSORTKEY convention
proposed by the OGIP group, because this convention is likely to be
very useful for tables: we have here at CDS (and in other data centres)
over thousand tables which can be translated into FITS, and for instance
the search capabilities on FITS tables can benefit a lot from the
knowledge of the sorting order.

However, the requirements imposed by the OGIP proposal (unique TTYPEs names,
usage of a restricted character set in TTYPEs names) do not match
the present standard,  while the TTYPE numbers (i.e. column numbers)
do not impose further constraints. 

Regarding OGIP FITS answers:

>  - It is more in the 'object oriented' spirit to refer to a column by
>    its name rather than absolute position within the table.  This
>    helps to insulate the creator and user of the TSORTKEY keyword
>    from having to know about the internal structure of the table.
>    This is similar to relational database systems that generally
>    refer to table columns by name rather than position.
 No. Look into your favorite DB system, you'll discover that 
 the definitions of the indexes are made of numbers. The DBMS of 
 course is able to map names into numbers and vice-versa. This mapping 
 can even be performed by a human being without too much trouble!

>  - If the columns in the table are rearranged, or if columns are added
>    or deleted in the table, then the TSORTKEY does not have to be
>    modified.   
 Such an operation implies a complete redefinition of the table definitions and 
 if the table data, and is normally done by a piece of software, which could 
 easily include the few lines of code to perform this mapping. 
 Furthermore, I don't think it would be advisable to introduce
 dependencies between the values taken by keywords, like the TTYPE
 and the TSORTKEY: renaming a column (changing just the value of
 a TTYPEs keyword) would have an impact on the TSORTKEY contents.

Concerning the position of NULL values in a sorted list (at the beginning
or at the end of the list ?) the answer is not obvious. For instance
in ASCII tables, the blanks are usually used to denote such values,
and are "naturally" (in the ascii order) situated at the top of the
list. The answer may be different for binary tables using IEEE floating-point
NULL values. What's the general opinion ?

Francois Ochsenbein / CDS Strasbourg