[TAP] draft 0.42

[Mark Taylor]

On Tue, 21 Apr 2009, Patrick Dowler wrote:

> I have just posted TAP 0.42 draft to the DAL WG page:

Pat, I have a few comments.

This is the first time I've looked closely at the TAP draft for a 
while, so some of the points may not be specific to version 0.42.

Sec 2:
   Is the formatting deficient in the discussion of RFC2119 terms?
   Looks like some of the terms named here should be in bold face.

Sec 2.2.1:
   Should "web-source" read "web resource"?

Sec 2.5:
VOTable:format column:
   I disagree with several entries in the "VOTable:format" column 
   (perhaps to be renamed "VOTable:content-type" or similar - 
   see previous messages) of the type table.  

   "STC-S" and "ISO8601" are fine.  However, the entries currently 
   labelled "hex? base64?" and "?" entries should be blank.
   In their capacity as BINARY/VARBINARY/BLOB/CLOB items, the
   uploader does not need to assert anything about their content
   other than that implied by their VOTable datatype.
   Again, see my earlier messages today for further clarification 
   on this.

Sec 2.5:
VOTable:arraysize column:
   Strictly requiring a value of "*" where noted here imposes an 
   unnecessary and inappropriate restriction on the uploaded table.
   Instead of "*", TIMESTAMP, POINT and REGION could equally have 
   some fixed (but non-null) value, if the software that generated 
   the VOTable has been able to determine the size of the field 
   in question.  VARCHAR, VARBINARY, BLOB and CLOB on the other hand
   might have arraysize values of the form "<n>*" - e.g. 100* means 
   a variable size up to a maximum of 100 - the RDBMS might make 
   some use of such information if present.

   So I'd suggest the following: 
     - Entries in the arraysize column of the table for TIMESTAMP, 
       POINT and REGION be replaced by a reference to a note with 
       text like '"*", or some other value indicating the actual 
       number of characters in the column (see the VOTable standard)".

     - Entries in the arraysize column of the table for VARCHAR,
       VARBINARY, CLOB, BLOB be replaced by a reference to a note
       with text like '"*", or some other value indicating the actual
       array size of the column (see the VOTable standard)".

   This is not a very important point though - in a high proportion
   of cases most likely "*" is what will be used for these types.

Sec 2.6.3:
   The "unit" entry has the description "unit in VO standard format".
   Is there a VO standard format for units?  If so, can you put a 
   reference in here to the relevant document.

Sec 2.7.1:
   I agree with Francois's comment that if you want to use CSV it
   would be a good idea to use the definition from RFC 4180 
   (which also defines MIME types) rather than providing a competing
   and incomplete definition here.

Sec 2.7.1 and Sec 2.9:
   The usual MIME type for VOTable is "application/x-votable+xml" 
   or maybe "text/x-votable+xml", not "text/xml; content=x-votable".
   "content" is not listed in the text/xml MIME type registration 
   (RFC3023) as a mandatory or optional parameter of the text/xml 
   MIME type.  RFC3032 also explicitly considers and rejects the 
   idea of using a parameter like this to specify XML subformats -
   see Appendix A.6.

   I'm not going to have a long argument about this (again) so if
   TAP wants to use "text/xml; content=x-votable" well go ahead,
   but be aware that you are using the MIME type in a deprecated
   (illegal?) way which may hinder interoperability.

Sec 2.7.2:
   "There *must* be one VOTABLE element per table in the dataset."
   Should this read ".. one TABLE element .."?

Sec 2.8.1:
   "query languages is versioned separately"
   should read
   "query languages are versioned separately"

Sec 2.9.1:
   "In an error occurs ..."
   should read
   "If an error occurs ..."

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/