PR-TAP-1.1 - Some comments

Grégory Mantelet gmantele at ari.uni-heidelberg.de
Thu Sep 7 11:36:20 CEST 2017


Hi DAL,

I have few comments about TAP 1.1, PR-2017-08-30.

First, I have noticed the following typos:

     - Section 2.2-{async}, page 10:
            "UWS specifies the name and semantics of **the a** small set of
             child resources used to view and control the job, e.g.:"
         => "UWS specifies the name and semantics of **a** small set of 
[...]"

     - Section 2.7.6-UPLOAD, page 17:
            "as TAP_UPLOAD.<tablename>, where <tablename> is the ****
             specified by the user."
         => "as TAP_UPLOAD.<tablename>, where <tablename> is the **name**
             specified by the user."

     - Section 5.1.2-Modify a Query Job Before Execution, page 28: (not 
being a
       native english speaker, I am not really sure of this one...so, 
sorry if I
       am wrong)
            "for TAP services it is recommended that this **be** set to the
             current time plus the maximum amount of time"
         => "for TAP services it is recommended that this **is** set to 
[...]"

     - Section 5.1.3-Running a Query, page 30:
            "Since services may impose a limit on the maximum wait time 
and may
             return before **ten** job reaches a final phase"
         => "[...] return before **the** job reaches a final phase"


Then, I have also few comments (mostly on details):

     - Section 2.4-/capabilities:
         In the given example, the XML schema of VODataService is in 
version 1.0.
         As far as I can see, there is now a version 1.1. This latter is 
also
         referenced in VOSI-1.1, section 3.3-Table metadata.
         Since this XML extract is given as an example, I assume it does not
         really matter in the sense that TAP-1.1 does not require the use of
         VODataService-1.1 or 1.0. I assume that is up to the TAP service
         implementor.
         => Is it correct?
         => Would it be a good idea to reference the version 1.1 in this 
example,
            considering that it is actually the version recommended in
            Section 2.5-/tables (i.e. Plante and Stébé et al., 2010)?

     - Section 2.5-/tables:
         Still about VODataService-1.1, I wondered whether it would 
interesting
         to briefly speak about the details levels described in 
VODataService-1.1
         (about the table metadata discovery). I know it is written in
         (Plante and Stébé et al., 2010), but since it is a very interesting
         feature for TAP services with a large table set, I think it 
would worth
         briefly mentioning it.

     - Section 4.1-Schemas:
         "The schema_name values must be unique and may be qualified by the
          catalog name or not depending on the implementation requirements."

         => Sorry if I come back on a quite old topic, but since table 
names can
            be qualified and/or delimited/quoted, would not it make sense to
            allow the same thing about schema names?
            If yes, we can add something similar to what is written in
            Section 4.2-Tables:
            "If the schema name is such that the name must be quoted (quoted
             identifier in (Ortiz and Lusted et al., 2008)) then the 
value must
             include the quotes."

     - Section 4.2-Tables:
         1. The column 'table_index' is declared with the datatype 'int' 
and the
            arraysize '1'.
             => Does it mean that it is an array of only one item?
                I don't think so. Then, would not it better if arraysize 
stays
                'null'?

         2. Nothing says that the column 'schema_name' must (exactly?) 
match one
            TAP_SCHEMA.schemas.schema_name entry.
             => I think some TAP clients, and especially STILTS/taplint, 
check
                this relation between TAP_SCHEMA.tables.schema_name and
                TAP_SCHEMA.schemas.schema_name. I assume that this 
relation is
                obvious/implicit (am I wrong?), but it would be however 
nice to
                state it anyway in TAP-1.1.

     - Section 4.3-Columns:
         1. Same comment about the columns 'size', 'indexed', 
'principal', 'std'
            and 'column_index' ; they are declared with the arraysize '1',
            implying that they are arrays...though they are not.

         2. As in Section 4.1-Schemas, nothing says that a column name 
can be
            delimited/quoted if not a regular identifier. It is written that
            "size" must be delimited because it is a reserved word in 
ADQL-2.0,
            but except this exception, nothing is stated about the 
values of the
            column 'column_name'.
            => Again, adding something like the following would be certainly
               enough:
               "If the column name is such that the name must be quoted 
(quoted
                identifier in (Ortiz and Lusted et al., 2008)) then the 
value
                must include the quotes."

         3. And still as in Section 4.1-Schemas, nothing mention the 
(exact?)
            equality relation between TAP_SCHEMA.tables.table_name and
            TAP_SCHEMA.columns.table_name, though this is again more or less
            obvious/implicit.

     - Section 5.2-Example: Synchronous Query:
         In the example of synchronous query, the parameter 
REQUEST=doQuery is
         provided.
         => From what I have read TAP-1.1 does not require this 
parameter anymore
            (and I will certainly not fight against that :) ).
            I know that DALI-1.1 specifies that services may use this 
REQUEST
            parameter if several operation mode are available but this 
is not the
            case anymore in TAP since TAP-1.1. So, of course, a TAP-1.1 
service
            will not complain about spurious parameters like REQUEST, 
but maybe
            the example would be cleaner without this REQUEST=doQuery.

Cheers,
Grégory



More information about the dal mailing list