TAP Implementation Issues (cont'd)

[Tom McGlynn]

[Third in a series]

2.3.1 What is a getCapabilities request supposed to do since we don't
have a capabilities record defined to return?

What is the appropriate value of REQUEST for async requests that do
not create the query?  The document indicates:
    A TAP client must set this parameter correctly in every request
    (GET or POST) to /async or /sync web resources.
I take this as meaning that invoking something like
    http://mytap/async/phase
needs a REQUEST.  If it means something else it needs to be clarified.

2.3.2/2.8 The whole version and version negotiation framework seems 
complex and ill defined.  E.g., what is the version of TAP that this 
document refers to.  I'm guessing that it's '1.0' but perhaps it 'TAP 
1.0' or whatever.   Specific examples of the strings to be used, 
especially the string that specifies the current standard is required. 
  There's supposed to be some sense of compatibility between versions 
x.a and a.b generally within the IVOA framework, but how that is to 
apply here is not discussed.

It is also unclear what a user is required to do.  E.g., can a data 
provider simply ignore this parameter.  In 2.8.2 there is a statement 
that the service 'declares the version it supports' but it's not clear 
to me how that is done.

In 2.8.3 there is a phrase "does not match a version available from the 
service at level two". I have no idea what this is.

Overall I'd recommend -- especially since this is the first version of 
the document -- that there should be a statement to the effect to the 
effect...

    "Services must accept the VERSION parameter but may ignore it."


2.9

The mandate to use VOTable 1.2 is a bit painful and I'm not sure it will 
be helpful.  I suspect that it will break some substantial number of 
clients.  Generally I think it is best when standards are coupled as 
weakly as possible.  While VOTable 1.2 may be needed to describe some 
ADQL types, there are many tables and queries that will not need these 
types (including all of the queries that I anticipate against the 
HEASARC).  I would have permitted any version of VOTable.

2.3.4

It's very hard to understand what is needed for a compliant TAP service
with regard to the geometry constructs.  E.g., if I want to support 
REGION, I'm told that need to use the STC-S format described in 
reference 4.  However that document doesn't discuss regions specifically 
and discusses lots of stuff that clearly is not part of the region, 
e.g., time intervals,  redshifts, etc...  For someone  -- like myself -- 
not familiar with the STC-S standard, the statement
    If the service suports the REGION function, it must support
    region encoding in the STC-S format[4]; the extent of the STC-S
    support within the region function is left up to the implementation.
is mystifying.  I'm guessing a little here but is this supposed to mean

    The string used in the REGION function should support region
    encodings specified in the STC-S format[4].  A region string will
    typically only include the 'space subphase' of an STC-S string,  A
    service may support only simple regions, e.g., CIRCLE's, ELLIPSE's,
    BOX's or CONVEX's (or some subset of these), or it may support
    combinations of these.  An example simple region specification is
    ....  A more complex region example is ...
would help a lot.

I think something like this would be far easier to understand -- and to 
scope implementation of -- than the current vague descriptions.

The lack of clear examples in the TAP, ADQL, STC and STC-S documents is 
a real handicap.

This also illustrates how difficult the TAP document is to use in 
building the standard.  While I have complained about an over-coupling 
of TAP and HTTP in the document, I  sometimes feel that the interface 
between TAP and other IVOA standards is underspecified.  There should be 
lots more examples.

I gather that if I do not support REGION I do not need to support any 
geometry functions?  If I want to support other geometry functions  but 
not REGION is that OK?  I didn't see anything in the ADQL document (on a 
quick run through) which indicated one way or the other.


---
There is a statement that timestamp values in ISO format need to be 
supported.  What does this mean for an actual database?  E.g., I don't 
have any SQL timestamp values in my database, so do I need to worry 
about this?  Are there any functions that take such strings and convert 
them that must be supported in my database even if I don't have 
timestamp columns?

I do have dates that I store internally in MJD.  Am I required to 
support queries against these columns using ISO formats?  If so what 
defines the columns for which such conversions are mandated?