TAP Implementation Issues (cont'd)
Thomas.A.McGlynn at nasa.gov
Wed Oct 21 08:49:03 PDT 2009
[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
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
"Services must accept the VERSION parameter but may ignore it."
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.
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; 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. 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
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?
More information about the dal