[TAP] draft 0.42

[Francois Ochsenbein]

Hi Pat,

Sorry for the length of this message -- I tried nevetheless 
to be as brief as possible in the enclosed comments related
to TAP Version 0.42. Some comments are just typos, but a
couple imply VOTable adjustments:

==> the usage of the <INFO> tag (sec. 2.9): should we (I mean the
      VOTable group) give up with the addition of sub-elements
      like <DESCRIPTION> in <INFO>, which are included in VOTable1.2 ? 

==> the 'format' as a new attribute of <FIELD> (and therefore
      of <PARAMETER>): I assume this word is replaced by 'encoding',
      with a similar meaning of what is proposed in Apx A.5 of 
      VOTable1.2. Is that agreeable ?

And thank you!
Francois

================================================================
Comments on [TAP] draft 0.42
================================================================

Introduction:
    I'm not sure about the 'web-service' term --
    doesn't it imply soap ?

1.1.1 : 
    for lisibility, assign the number to the 4 kinds of query
    (1) data queries (2) metadata queries etc

1.3  ... go to COMPLETED or ERROR. The results, or an error document 
         can then by retrieved.. 
    by --> be
    languge --> language

2.3 2nd (last) paragraph: 
    it may be difficult to decide which is a spurious parameter -- in a
    set of n parameters, it is likely possible to find several subsets
    which would represent a valid tap request. Or are you talking about
    empty parameters only (cf 2.3.11)? The exact situation should be
    clarified, in my opinion.

2.3.1  It a TAP service such a receives a request...  
    remove the 'such a'?

2.3.4 + 2.3.5 :
    as you suggest, most of the section 2.3.5 would better be
    in a PQL document.

    Or alternatively the TAP document could have a section dedicated to
    the queries by (celestial) position and maybe another section to
    queries by time. Queries based on position (and time) are such an
    important part of TAP that a few typical examples, in both ADQL and
    PQL, would be helpful for both TAP servers and clients (consumers).

    As a side effect of your remarks at the end of section 2.3.4, it
    becomes obvious that you can't require an ADQL query to return an
    ICRS position; it would be a good suggestion, at least for
    efficiency, to suggest the TAP servers to insert in their table
    schema columns with ICRS coordinates.

2.3.6 : why is tab-separated-values not considered ? 
    tab-separated-values is a mime type which exists since the
    beginning of the web, and is much more simple than CSV 
    (does not require optional escaping, but forbids documents
    having tabs in their columns). See also 2.7.1

2.3.9 :
    I really do not understand why MTIME is introduced in TAP, it
    introduces a lot of complications and exceptions in the definitions 
    of the TAP service; I believe the TAP protocol should stay as generic
    as possible. Isn't it possible to define alternatively a specific
    schema (or data model?) for logs or 'mirrorable' tables ?

2.3.11 : 
    my feeling is that MAXREC= (parameter without value) differs
    fundamentally from asking for a default or null value, and is
    related to 2.3 (2nd paragraph): is it a spurious parameter or
    a request for a default value ? My own opinion is that parameters
    without contents would better be systematically ignored
    (i.e. http://my.tap-server/tap/sync?REQUEST=doQuery&MAXREC=
     and  http://my.tap-server/tap/sync?REQUEST=doQuery
     represent the same TAP query -- that would be the logical
     interpretation of what comes out from a HTTP form)

2.3.13 : 
    is there a well-defined way of dealing with multi-valued 
    parameters (your TBD) ? What would happen if you specify 
    first MAXREC=100, and somewhere else in the same query MAXREC=0 ? 
    A duplication of parameters like MAXREC or RUNID should, 
    in my opinion, generate an error.

2.5 :  table with correspondance VOTable / ADQL:
    -- VOTable:format  --> VOTable:encoding
    -- TIMESTAMP : is defined in DBMSs, but is it with time zone
       or without (i.e. UTC) ? 
    -- VARCHAR and VARBINARY have a size VARCHAR(n) or VARBINARY(n);
       in VOTable, the arraysize is n* (a number followed by the *)
       (see also 2.6)
    -- BINARY, VARBINARY and BLOB should, be default, be written
       as an array of decimal numbers in VOTable, e.g. 
       12 56 0 255 0 0 255 ...
       A possible 'encoding' could effectively specify hexa or base64 

2.5.2 : table upload:
    Is it restricted to VOTable ? And if yes, only to <TABLEDATA> 
   version of VOTable ?  Or shouldn't any of the output types 
   defined in 2.3.6 be acceptable ? 

2.6 : TAP_SCHEMA
    as already repeated (not only by me!) the current definition is
    incomplete for what concerns the actual table implementation 
    (keys and indexes). If the TAP_SCHEMA is limited to semantics
    (i.e. remove the 'indexed' in the columns schema), it's OK.

    And if ADQL (SQL) datatype replaces the VOTable datatype,
    shouldn't also the [array]size be removed (see also 2.5)?
    The phrase "this size does not map to the VOTable arraysize
    attribute" could also then be removed.

2.7.1 : 
    (about MTIME: see 2.3.9 above)
    about CSV: it is defined by RFC 4180, and should not be
    (incompletely) redefined here. 

2.7.5 :
    "If the output format is VOTable, section 2.7.5 describes the method"...
    this definition looks like an endless loop :-)

2.8.1 : 
    the IVOA documentation standard from
    http://www.ivoa.net/Documents/DocStd/20090302/PR-DocStd-1.2-20090302.html
    specifies in its section 1.2, item#3:
    A version number of the form I.J, where I and J are integers 
       0, 1, 2, ... 9, 10, 11, ... .
    therefore I don't understand how "1.23" is interpreted as "1.2.3" ??

2.9 : (VOTable)
    -- First the question of the INFO tag: the explanation text must be
       included in a sub-element <DESCRIPTION> in VOTable1.2 ;
       Mark Taylor insisted this should be removed (incompatibility
       with previous version) but on the other hand the modified
       <INFO> gives more possibilities (e.g. is list of options).
       A final decision about this should be taken soon...
    -- 2.9.1 : how to specify an overflow seems contradictory :
       * before the result: "OK" specifies success + no overfolw
       * after the result: specify "overflow"
       Should a correct interpretation be:
       1. Before the result: OK means the query is understandable
       2. After the result: OVERFLOW or OK (or nothing ? )
=======================================================================
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
=======================================================================