Comments on TAP-0.31
francois at vizir.u-strasbg.fr
Mon Dec 22 09:35:38 PST 2008
Just before the holidays I had a look to the V0.31 TAP specifications;
sorry for being late -- but I hope it's still not too late.
The comments are not ordered by section, I tried to summarize
my concerns in 4 points (VOTable questions, mime type question,
metadata, and time); I hope I'm not disturbing your holidays !
And I would like to thank the authors (Guy, Pat, and Doug) for the
present state of the document -- many clarifications occured already!
And let me wish happy holidays !
P.S. I should be present at the forthcoming AAS meeting in Long Beach;
it could be an opportunity for some (short) discussions.
A. could it be possible to recommend the version 1.2 rather than 1.1 ?
V1.2 is not yet a recommendation but should be (before TAP becomes
a REC :-). At least the following changes in VOTable1.2
would be better taken into account:
1. In VOTable1.2 the <INFO> tag may exist at the end of a <TABLE>.
There is therefore no need to write another table as explained
in section 2.8. VOTable1.2 included this modification exactly
for this purpose: issue diagnostics at the end of a streaming process
2. In VOTable1.2, the <INFO> tag can't include directly text
should be e.g.
<INFO name="QUERY_STATUS" value="OVERFLOW">
Number of table rows exceeds default limit of 5000
Doug complained about this feature at the last interop
meeting; on the other hand, this addition of the
<DESCRIPTION> element gives more room for extensions.
B. The mime types of the result
I feel uncomfortable with the mime type mentioned in section 2.8.1 :
VOTable1.2 recommends application/x-votable+xml, and here the
VOTable result requires another mime type. And requiring different
mime types for table upload versus data results looks like a useless
complication (a result can't be directly uploaded to another TAP
service). It both mime types are equivalent, we could modify the
VOTable document to accept both (it's not yet too late!)
C. The metadata and TAP_SCHEMA: I have still problems with the
way it is defined.
1. First we have to ensure that this schema is fully compatible
with the Registry (VODataService). Are all the elements there ?
2. It seems to me that entities like indexes and keys, which
definition requires an ordered set of columns (not a single
column!) cannot be in the TAP_SCHEMA.columns (and can't
either be in the TABLE_SCHEMA.tables).
3. Should not the dates of creation / last modification be
part of the TAP_SCHEMA concerning schemas and tables ? It's
in relation with section 2.4.8 (MTIME): when individual
modifications (at the row level) are not available, it
would be useful to get such dates to be aware that
modifications occured or not since some date.
D. Questions of time
I'm wondering what is the rationale on the repetition of the usage
of the ISO8601 for time ? It's found in 2.4.2 (query), 2.4.8 (MTIME),
2.10.5 (where), 2.11 (numeric and boolean values), 2.12 (usage of
VOTable). Is it there to restrict the usage of date/time to
UTC-only (ISO8601 does not deal with other time definitions) ?
Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg
11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 17
More information about the dal