TAP-1.1 columns.column_index info

[Marco Molinaro]

Dear Tom,

2018-01-12 16:23 GMT+01:00 Tom McGlynn (NASA/GSFC Code 660.1) <
tom.mcglynn at nasa.gov>:

> 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]
>

this is solve, in my view, in adding or not the column
into the TAP_SCHEMA itself, so no problem there.


>    If it is shown in what order should it be shown?
>

and this is what the column_index was introduced
for in TAP-1.1. I'm chatting on: if I don't put integers
in column_index for all my columns, is this an issue?
How do clients react to this.

Mark's answer was fine to me, however...


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

this idea of "overloading" the ordering using
abs(column_index) vs. only_positive(column_index)
is interesting.

What let's me concerned is that this is application
dependent: i.e. it won't work in all clients.
Do you know how topcat sees it, e.g.?
Does it put the negative values on top?

For sure, if people likes this or a similar
solution to allow nested-ordering using
column_index, we'll need to put some
words into the spec to be sure we all
use the same hacks.

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.


I agree on this latter.

Cheers,
    Marco


>
>     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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20180117/4372191a/attachment.html>