TAP 1.1 comments

[Mark Taylor]

On Mon, 9 May 2016, Patrick Dowler wrote:

> comments below
> 
> On 8 May 2016 at 16:55, Walter Landry <wlandry at caltech.edu> wrote:
> > Hi Everyone,
> >
> > Here are some comments on the TAP 1.1 proposal.
> >
> > 1) The text proposes
> >
> >      INTERSECTS and CONTAINS are required. POINT, CIRCLE, and POLYGON
> >      are required. POINT (and point-valued columns) cannot be used as
> >      an argument to INTERSECTS.
> >
> >    What is the rationale for not allowing POINT's in INTERSECTS?
> 
> It is redundant with CONTAINS and iirc some people found INTERSECTS
> decaying to CONTAINS a pain to implement...
> 
> > 2) The text says
> >
> >      A query with MAXREC=0 can be used with a simple query
> >      (e.g. SELECT * FROM some_table) to extract and examine the
> >      VOTable metadata (assuming FORMAT=votable). Note: in this version
> >      of TAP, this is the only mechanism to learn some of the detailed
> >      metadata, such as coordinate systems used.
> >
> >    I thought that TAP_SCHEMA.columns has all of that metadata?
> 
> There is no coordinate system metadata in the tap_schema.
> 
> > 3) I would really like to add a requirement that TAP/async jobs run
> >    immediately if the parameter PHASE=RUN is passed during the initial
> >    submission.  As I understand it, this was always intended to be
> >    true, but was never specified.  I can work on the text if needed.
> 
> If this behaviour is specified in UWS-1.1 then it is the case already.
> If not, then I don't think TAP is the place to do this... we could
> clarify this point, but restating things from other specs usually only
> leads to confusion.

UWS is agnostic, or at least not really explicit, about this.
UWS 1.1 section 2.2.3.1 says:

   This initial POST will in most cases carry parameters for the protocol
   that is using the UWS pattern, as detailed in 4 .In addition for the
   initial post may contain job control parameters if allowed by the
   implementing protocol (i.e. if UWS job control parameter names do
   not clash with the implementing protocol parameters). One use of this
   facility might be to have the job placed into a potentially running
   state by adding ?PHASE=RUN query part to the job creation URL.

TAP could state that it does in fact allow PHASE assigment at
job creation time, but since it doesn't currently do that,
I've interpreted it from a client point of view that I can't rely
on that behaviour, so topcat first creates a UWS job and then
assign its phase in a second step.  I think it would be a reasonable
idea for TAP 1.1 to explicitly state that PHASE can be set
(or maybe, just can be set to RUN) at job creation time.
If that happens, then I'd aim to get topcat/stilts to actually
do that for TAP 1.1 services (if I can identify them as such).

Note that doesn't get Walter completely off the hook, since TAP
clients would still be permitted to first create, and then set
PHASE=RUN in a second step.

Mark

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