TAP issues

[Markus Demleitner]

Dear DAL group, in particular TAP folks,

I am about to embark on a TAP implementation and browsed through the
0.31 draft.  After that first round, I found some issues that I
thought I'd bring up, hoping I'm not dragging up horses already beaten
to death.

(1) The TAP_SCHEMA tables have one field utype -- what happens if,
say, a table corresponds to more than one data model?  Do you
actually want to exclude that?

(2) 2.4.11 Range-list parameters -- I'm not sure I'm happy that we
start yet another syntax for purposes like that. I trust you had
good reasons to disregard ASU.  

However, I think the ASU experience at least tells us that mixing
values and operators in a rather haphazard way (i.e., without
rigorously defining what literals look like) is asking for trouble.
We have to deal with funky values (pairs, strings), and if we start
defining syntax on them, we should do it properly from the start (or,
preferably, avoid having to do so).

At least for enumerations, the standard HTTP URL syntax offers a way
around "embedded syntax" -- just give the same argument multiple
times, quite like forms to with selections or checkboxes.  Presto, no
(extra) trouble with escaping.

Similarly for ranges, I'd prefer to get the "operator" out of band,
e.g., by defining "magic" names (there are reserved parameter names
anyway, why not reserve everything starting with _OPR_ and then say
_OPR_MAX_<colname> or similar?).

The only alternative that I think will not come back and haunt us
later is to strictly define literals, e.g., using SQL syntax.  

(3) Most importantly, I was really unhappy about the should-clause in
2.4.2 according to which mixing literals and column references in
geometries should be an error.  You propose something like
CIRCLE(t.coordsys, t.ra, t.dec, 0.1).  This would mean that tables
would have to have coordsys columns, I gather.  Even if you can fake
this with views, I think that's a massive wart, because in general,
most aspects of the coordinate system are table metadata, and in
cases in which a part of the the system is not (e.g., mean epoch or
similar), I certainly have no desire to keep the epoch in, say, STC/S
strings in every table row.

Now, I've never been a big fan of the infamous first argument to
geometries in ADQL, but ok, it seems it's here to stay.  If so,
wouldn't it be much better to just require something like
CIRCLE(NULL, t.ra...) with column references, meaning "whatever
coordinate system the table has"?  

By the way, even the t.coordsys convention wouldn't protect users if
you had a table like

sys1   sys2   ra2000  de2000   ra1950  de1950
J2000  B1950  ....

-- nothing would keep people from specifying POINT(sys1, ra1950,
de1950), and so we're not better off than now, when POINT('ICRS',
ra1950, de1950) is still legal, right?

(4) Finally, is there a TAP implementation out there that has source
available and has at least most features in place?


Cheers,

        Markus