TAP1.0 Comments

[Francois Ochsenbein]

Hi,

About TAP WD1.0 (2009-06-07): this new version looks much better 
than the previous version, thank you Pat !

Mark Taylor and Alberto Micol already commented this last version,
and I second Mark's remarks. In the following there will be
some repetition with Mark and Alberto's remarks, but that's
unavoidable...

First, the question of TAP result in a single *table* : Alberto's
question is quite right, and I'm afraid the reduction of the 
result to a single table will generate problems for us (vizier)
and likely for other services. Yes the relational model implies
that the result of any query is a single table -- but sticking
to this means that queries like "give me all objects from any
table this region of the sky" is not possible. Such questions
however are quite frequent... How to deal with those ? I see
only the following alternatives if TAP sticks to a single
output table:
a. the client asks for tables existing in the service;
   upon the answer (7896 tables), the client generates
   7896 queries. Not really realistic :-(
b. the server creates some kind of minimal common schema
   between all these tables -- in practice this can only be
   the position and the table name (i.e. a 3 column table).
   But then you have to get more details about each result,
   details concerning data and as well as metadata. 
   Therefore you still have to generate many 'children' queries.

Or should services like vizier give up with TAP ?


The other questions I've noticed:

2.3.4 (and other places where ISO8601 is quoted):
     as far as I know, this norm requires the 'T' in front of the
     time; the timestamp format should therefore be written
     "yyyy-MM-dd[Thh:mm:ss[.sss]]" (the 'T' is missing in the document)

2.3.5: it looks strange for me that constraints can be ignored in PQL.
       If a table is queried with just a contraint on TIME, and there
       is no time in the table, the fact that this parameter is 
       ignored results in a dump of a (potentially very large) table.
       Similarly for POS query (section 1.1.5) -- if the table
       queried has no position, is it really a good solution to
       return the whole table ? Hopefully this is not possible
       with ADQL :-)

2.3.6 (as Mark noted) : why should the VOTable result be 
      limited to TABLEDATA format ?
      In addition: why is ascii FITS table not acceptable ?

2.3.8: MTIME -- I still have problems with this. A service may have
      some tables which have such timestamp columns (typically
      TAP_SCHEMA tables) while other tables have not this information.
      I can't therefore see this feature as a service-wide feature,
      and the MTIME capability would need to be specified in 
      the TAP_SCHEMA (section 2.6.2)

2.3.9: RUNID -- is it just a number ? In any case, it would be
     useful to specify which characters are valid in this RUNID
     (not specified either in section 5 and subsections therein)

2.5: again I share Mark's remarks concerning
     * (no arraysize of xtype): what does it mean ?
     * the inconsistency with VOTable (the PR VOtable1.2 document
       specifies "iso8601" and "STC-S" as agreed at the last IVOA
       meeting). At this meeting, did we mention between POINT 
       and REGION as 2 different datatypes ?
    In the table, the column 'arraysize' should contain 'n*' for
    VARCHAR(n) and VARBINARY(n) in order to be consistent with VOTable;
    for types BLOB, CLOB, STC-S, the column 'arraysize' should contain
    an asterisk (*). For TIMESTAMP, the column 'arraysize' should also
    contain a value (either *, or a value like 10 for a date or 19
    for timestamp accurate to 1s)

2.5.1: if the url points to a VOTable, why not using the table
    names defined in the VOTable document ? And can the url
    refer to a multi-table VOTable input ?

2.6.2: would be useful to specify here the MTIME support (see 2.3.8)

2.6.3: 'indexed' may refer to the first column in a multi-column index
     
2.6.4: in the paragraph starting by 
       "Data types and how they map to VOTable datatypes"...
     * phrase "this size does not map to the VOTable arraysize"...
       why ? It does, or did I miss anything there ?
     * "Indexed", cf 2.6.3 above

2.7.1: result as a single table: cf discussion above (First point)

2.7.4: "No method of reporting an overflow is defined for formats
     other than VOTable": this is really a potential source of
     huge problems, I don't think TAP could propose output formats
     where it's impossible to assess the correctness of the result.

2.9.1: INFO problems, as reported by Mark

About VOTable1.2, the RFC period should start quite soon --
the final documents to be reviewed is visible from the
VOTable page 
  http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/IvoaVOTable

--Francois
=======================================================================
Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24 24 17
=======================================================================