TAP-1.1 columns.column_index info

[Tom McGlynn (NASA/GSFC Code 660.1)]

Dear Marco,


This seems a bit of a kludge but I think that's inevitable since
there are two separate questions that you are trying to answer with one field:
    Whether the column should be shown by default? [or maybe some less binary column priority]
    If it is shown in what order should it be shown?

We frequently run into cases where a column is not a default column, but it is still
useful to talk about how it should be ordered when it is displayed -- usually in
relation to some other column.  E.g., you might not show the errors in some
quantity by default, but if the errors are shown, then you probably want them to
show up immediately after the quantities they are the errors for. Or you might not show
galactic coordinates by default, but when you do you want the longitude and
latitude to be next to each other.

Internally at the HEASARC use a very similar metadata to TAP, but rather than using nulls to define
the 'secondary' columns, we use negative values.  Negative values are ignored
by default, but if the user requests to see all columns, then we order by
the absolute value.  This means that when using default only default columns
the order values generally have gaps, i.e., the default columns might have
ordering 1,2,4,6,10  where the gaps would be filled if the user requested all columns.

I admit this is also a kludge.  The 'correct' solution (IMO) would be to have these
two distinct pieces of information separated into separate metadata fields, but that's probably
too much change for too little benefit.

To address your actual question, I think the loss of the ability to suggest an order to non-default 
fields
is non-trivial, but presumably where it causes problems for users they can
make sure to specify an explicit order.

     Tom McGlynn


Marco Molinaro wrote:
> Dear DAL/Apps-ers,
> in updating the TASMAN TAP_SCHEMA manager application,
> on the way to let the app user decide the column ordering
> (i.e. filling up the TAP_SCHEMA.columns.column_index values)
> we are going the following way: let the user define ordering on
> the important/preferred columns while leaving "unordered" the
> other columns.
>
> That is: we may have a bunch of NULLs alongside integers as the
> column_index values.
>
> TAP-1.1 latest revision is not preventing this.
> My only question is: will applications be OK with this?
>
> The intent is to have the NULL-annotated-column_index
> columns fall (potentially) unordered after the ordered
> ones when rendered into the client.
>
> Comments?
>
> Cheers,
>     Marco
>