<div dir="ltr">Dear Tom,<br><div class="gmail_extra"><br><div class="gmail_quote">2018-01-12 16:23 GMT+01:00 Tom McGlynn (NASA/GSFC Code 660.1) <span dir="ltr"><<a href="mailto:tom.mcglynn@nasa.gov" target="_blank">tom.mcglynn@nasa.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Marco,<br><br>
This seems a bit of a kludge but I think that's inevitable since<br>
there are two separate questions that you are trying to answer with one field:<br>
Whether the column should be shown by default? [or maybe some less binary column priority]<br></blockquote><div><br></div><div>this is solve, in my view, in adding or not the column </div><div>into the TAP_SCHEMA itself, so no problem there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If it is shown in what order should it be shown?<br></blockquote><div><br></div><div>and this is what the column_index was introduced </div><div>for in TAP-1.1. I'm chatting on: if I don't put integers</div><div>in column_index for all my columns, is this an issue?</div><div>How do clients react to this.</div><div><br></div><div>Mark's answer was fine to me, however...</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We frequently run into cases where a column is not a default column, but it is still<br>
useful to talk about how it should be ordered when it is displayed -- usually in<br>
relation to some other column. E.g., you might not show the errors in some<br>
quantity by default, but if the errors are shown, then you probably want them to<br>
show up immediately after the quantities they are the errors for. Or you might not show<br>
galactic coordinates by default, but when you do you want the longitude and<br>
latitude to be next to each other.<br>
<br>
Internally at the HEASARC use a very similar metadata to TAP, but rather than using nulls to define<br>
the 'secondary' columns, we use negative values. Negative values are ignored<br>
by default, but if the user requests to see all columns, then we order by<br>
the absolute value. This means that when using default only default columns<br>
the order values generally have gaps, i.e., the default columns might have<br>
ordering 1,2,4,6,10 where the gaps would be filled if the user requested all columns.<br>
<br>
I admit this is also a kludge. The 'correct' solution (IMO) would be to have these<br>
two distinct pieces of information separated into separate metadata fields, but that's probably<br>
too much change for too little benefit.<br></blockquote><div><br></div><div>this idea of "overloading" the ordering using </div><div>abs(column_index) vs. only_positive(column_index)</div><div>is interesting.</div><div><br></div><div>What let's me concerned is that this is application</div><div>dependent: i.e. it won't work in all clients.</div><div>Do you know how topcat sees it, e.g.?</div><div>Does it put the negative values on top?</div><div><br></div><div>For sure, if people likes this or a similar</div><div>solution to allow nested-ordering using</div><div>column_index, we'll need to put some</div><div>words into the spec to be sure we all</div><div>use the same hacks.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To address your actual question, I think the loss of the ability to suggest an order to non-default fields<br>
is non-trivial, but presumably where it causes problems for users they can<br>
make sure to specify an explicit order.</blockquote><div><br></div><div>I agree on this latter.</div><div><br></div><div>Cheers,</div><div> Marco</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Tom McGlynn</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
Marco Molinaro wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear DAL/Apps-ers,<br>
in updating the TASMAN TAP_SCHEMA manager application,<br>
on the way to let the app user decide the column ordering<br>
(i.e. filling up the TAP_SCHEMA.columns.column_inde<wbr>x values)<br>
we are going the following way: let the user define ordering on<br>
the important/preferred columns while leaving "unordered" the<br>
other columns.<br>
<br>
That is: we may have a bunch of NULLs alongside integers as the<br>
column_index values.<br>
<br>
TAP-1.1 latest revision is not preventing this.<br>
My only question is: will applications be OK with this?<br>
<br>
The intent is to have the NULL-annotated-column_index<br>
columns fall (potentially) unordered after the ordered<br>
ones when rendered into the client.<br>
<br>
Comments?<br>
<br>
Cheers,<br>
Marco<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div></div>