PR-TAP-1.1 - Some comments
Patrick Dowler
pdowler.cadc at gmail.com
Thu Sep 7 17:30:10 CEST 2017
I will make all these changes asap. Thanks for the (obviously) detailed reading,
Pat
On 7 September 2017 at 02:36, Grégory Mantelet
<gmantele at ari.uni-heidelberg.de> wrote:
> 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
>
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
More information about the dal
mailing list