Mapping of TAP_SCHEMA.columns.principal to SCS VERB

[Mark Taylor]

On Tue, 10 Oct 2017, Markus Demleitner wrote:

> Hi,
> 
> On Mon, Oct 09, 2017 at 03:32:40PM -0700, Walter Landry wrote:
> > In the current TAP PR, TAP_SCHEMA.columns.principal is an integer.  Is
> > the intention to make that map to the same meaning as SCS's VERB?  It
> > seems that the meaning is somewhat inverted.  So
> > 
> > SCS VERB    TAP principal
> > 1           2
> > 2           1
> > 3           0
> 
> Hm -- frankly, I think I'd like that.  I'm always fond of
> streamlining things between the various protocols.
> 
> The question is: Will this break any client?  And if it were, would
> the breakage be serious?
> 
> Client writers: Do you do anything with principal?

Speaking for topcat: no (apart from display it), and if I did
I would as a matter of general practice test for zero-ness
rather than require either-zero-or-one.

But, I'll note that this column is an integer as a matter of
accident; like the nearby "indexed" and "std" columns its
intention has always been boolean (it did in fact appear as
boolean in at least one recent draft), it's only integer
because there's no boolean type available for use here.

My feeling is that if we were writing SCS and TAP from scratch
and in parallel, yes it would make sense to synchronise the
representations between the two.  But given the current state
of the two protocols, it's not obvious to me that the benefits
of this alignment would outweigh the negative effects of the
semantic change it represents.

But, none of my client code would break if such an alignment happens.

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/