Comments on TAP1.0 Chapter 2

[Alberto Micol]

Here attached my comments on Chapter 2 of TAP.

I find al the following comments a bit too long to put them in the RFC  
page,
hence this email. If this is not the correct way to proceed while in  
RFC phase, please let me know.

First the most important ones (sorted by paragraph, not by importance),
then, some minor but still useful (I hope) proposals to increase  
readability
or usability.

I do not provide comments here to the /sync /async and VOSI issue,
I reserve it for a later email ;-)

Neither I do provide comments to the UPLOAD mechanism: I'm still  
digesting it!
I find difficult to understand all its implications, like:
- how to chain TAP services,
- how to upload a table of regions to formulate INTERSECTs cross- 
matches,
  etc.
Some examples would be so darn useful!
(I already sent some emails regarding chaining, and the fact that an
output VOTable should not, unfortunately, contain more than one table)

Many thanks to the authors!

Alberto

---------------------------------------------------------------------

par 2.3.6 FORMAT: I would have claimed useful to optionally support  
latex (application/x-latex);
can a service use a FORMAT not listed in that table?
This should be clarified in that pararaph.
-- The sentence "should reject queries with unsupported formats" might  
be read in two ways:
-- 1. a latex query is to be rejected by my service
--    because is not listed in the TAP FORMAT  table
--   (despite the fact that my service supports it)
-- 2. a latex query is accepted by my specific service 
--   because my service  supports latex
--   (despite the fact that it is not mentioned in the TAP FORMAT  
table).
-- Which one of the two is valid? if (2) is valid, how does someone get
-- to know that such service supports latex (it is not listed in the
-- getCapabilities, is it?) ?


par 2.3.8 MTIME utypes
Some utypes (Record.Modified and Record.Deleted) have been introduced  
for MTIME.
It makes me think that a Data Model for a Record exists, but nowhere  
is it mentioned in the document.
A utype should not be created by a protocol.
I think UCDs should be created and used instead.


par 2.3.12 When request parameters are duplicated with conflicting  
values, the response
from the service is undefined (may reject or pick up any value and  
continue).
Wouldn't be better to impose the service to fail (and issue a specific  
error) in such cases?
The risk of providing the wrong answer, without the user noticing, is  
in my opinion not acceptable.


par 2.6 Overall, the referential integrity is not enforced through the  
mentioned tables.
-- It could be that one sets
-- schema_name =  "toto" in schemas,
-- while using
-- schema_name = "pippo.toto" in tables.
-- Similarly with the table_name between tables and columns, etc.
It is not clear to me if this could cause problem to an external  
client developer, but it is somehow disturbing.


par 2.6 on the possible values of primary, indexed and std columns
The definitions of the TAP_SCHEMA tables does not include
the attributes' datatypes and sizes, nor if they can be null or not.
-- I guess this is not to force people to use relational databases(?)
The problem is with the some columns like: primary, indexed, std
are those supposed to be booleans? If not, what are the possible values?
Wouldn't be better to explicit this?
What if a service uses booleans and another char(1) (Y|N) instead?


par 2.6.1 Schemas
Such table is useless if my dbms does not support schemas,
nevertheless in 2.6 and in 2.6.4 is written that services must provide  
it.
How to get out of this impasse? changing "must" into "should"?
Providing a schemas table with no records?



Minor, mostly editorial, changes:
--------------------------------------------

Not in Chap 2, but an old comment of mine on paragraph 1.1:
http://www.ivoa.net/forum/dal/0907/1396.htm
That comment (on disentangling Query Types and Query Language)
was accepted, but never implemented.
Is there any special reason for that, or it was only forgotten?


par 2.3.2 references section 2.9.2, should be 2.8.2

par 2.3.3 at the end references 2.9, should be (more precisely) 2.9.2.

par 2.3.5  a reference to PQL-0.1-20090212 is mentioned but not given;
it should also be added in chapter 8 References.

par 2.3.5 ISO8601 inconsistency: the T separator is mentioned in the  
TIME=2009-01-01T12:00:00
example, but immediately after it is stated that PQL must support  
timestamps without the T.
One or the other...

par 2.3.6 uploading a votable using TABLEDATA
indeed that senetence is not only found in 2.5 but also in 2.3.6

par 2.3.7 MAXREC=0
Last sentence notes that this is the only way in tap1.0 to get
to know the coordinate systems used by a service.
This is so important that it should be (1) highlighted
and (2) should be repeated in 2.6 "metadata tables and tap schema".

par 2.3.8 MTIME
It should be highlighted that:
  if in use it *must* use UTC and ISO8601,
as it is done with *must* add extra columns later in the same par.
(My feeling is that UTC might get forgotten otherwise)

par 2.5 the last occurence of the word POINTs should read REGIONs  
instead.

par 2.5 Table Upload
It would be sooo nice to have an example of its usage...


2.6.4 size for variable length datatypes:
"this size does not map to the VOTable arraysize attribute"
but the table in 2.5 shows the mapping between the two.
It seems contradictory. What is it that I do not understand?
Could that be clarified for those like me?

par 2.7.1 both sentences where it reads "CSV (and TSV)" data must be  
returned
with a mime type..."  should highlight the *must*.

par 2.7.3 states that TAP distinguishes three classes of exceptions,
but then only two bullet items are provided.
My guess is that the second one counts for two, but that could
be rewritten to avoid this kind of guesses. (btw, is my guess correct?)

par 2.8 incipit
VOA Registry is not a standard, is subject to changes, and it could be  
that
other registries similarly support the same functionality: hence it  
should not be mentioned.

par 2.8.1 ends stating that Version numbers follow IVOA document  
conventions.
hence par 2.8.2 should be removed completely, to avoid clashes if/when
the IVOA convention will change (or could be given as a footnote stating
that this is only the "current" situation, but clearly indicating that
the IVOA document convention will always take precedence.


par 2.9 references votable 1.2 [9], but [9] is actually votable 1.1
(awaiting for the new one I guess; pleas do not forget to change it  
when 1.2 gets approved)


par 2.3.12 clean a double "for".


par 2.9 Use of a VOTable
That paragraph only explains the "result" votable,
not the uploaded votable (explained in 2.5).
It would be better to reflect this in its title (Use of a VOTable  
response ?)
(I was looking in 2.9 for info on how to use a votable as input/upload)

par 2.9.1 About the multiple INFO elements with name QUERY_STATUS:
The first QUERY_STATUS is there to state if the query is being
executed, or if an error occured before execution time.
The second QUERY_STATUS would inform of an error or overflow
during query execution.
Wouldn't be better to explicit that in the possible values, and use  
something like:

<INFO name="QUERY_STATUS" value="SUBMITTED"/>
<INFO name="QUERY_STATUS" value="ERROR"/>

<INFO name="QUERY_STATUS" value="OVERFLOW"/>
<INFO name="QUERY_STATUS" value="ABORTED"/>
<INFO name="QUERY_STATUS" value="OK"/>

where obviously the first two are for the first query_status,
while the last 3 are for the second one ?
No a big deal, but I always prefer to have unique status values.

Also, the language or version errors mentioned in 2.9.2
could be reported in the DESCRIPTION part of the INFO element.


Missing paragraph: Multi-position searches
I was looking for more information on how to achieve a multi-pos search,
but nor par 2.5 nor 2.9 provided any information.
It is only by chance that I found what I wanted looking into the 2.3.5  
paragraph Parameters for PQL.
I claim that it would be quite useful to dedicate a little paragraph  
to such important ability, showing example of how to do it with both  
PQL and ADQL.

--- end of message ---