TAP-1.0 Erratum 1: UPLOAD Table Names

Author: DAL WG

Date last changed: 2014-12-22

Date accepted: 2017-05-14

Rationale

Section 2.5 of TAP-1.0 requires the name of the uploaded tables to be a

... legal ADQL table name with no catalog or schema (e.g. an unqualified table name)

This may allow ADQL-2.0 delimited_identifiers to be used for uploaded tables as the ADQL table_name expands to either regular_identifiers or delimited_identifiers. This, however, was clearly not the intention of the text, as the use of delimited_identifiers is not (fully) supported by the syntax of the UPLOAD parameter (see §2.5.1 in TAP-1.0), i.e.

UPLOAD=table_a,http://host_a/path;table_b,http://host_b/path

To clarify this issue, the proposal has been made to replace the text within parenthesis in the above quoted excerpt of TAP-1.0 to allow in the UPLOAD parameter only table names as strings following the regular_identifier ADQL syntax.

Erratum Content

The TAP-1.0 recommendation states, for the table upload mechanism (see §2.5 of TAP-1.0), that

The client specifies the name of the uploaded table; this name must be a legal ADQL table name with no catalog or schema (e.g. an unqualified table name).

The parenthetical exemplification may allow any ADQL-2.0 identifier to be used as a string in the UPLOAD parameter posted to the TAP service accepting uploads, including delimited_identifier ones that the UPLOAD parameter syntax doesn't support.

This Erratum updates the TAP-1.0 recommendation amending the third sentence in the first paragraph of §2.5 of that document by substituting it with the following:

The client specifies the name of the uploaded table; this name must be a legal ADQL table name with no catalog or schema (i.e. a string following the regular_identifier production of the ADQL-2.0 standard).

Impact Assessment

This Erratum emendation could, in theory, invalidate existing clients that might want to use delimited_identifiers in uploads. Due to the difficulties with the UPLOAD parameter syntax, however, that would not really be supported in TAP-1.0, either. This solution, thus, clarifies the TAP-1.0 document and will be maintained in the next minor version of the protocol itself.

Note

This Erratum was previously part of the TAP1Err1 Note still available on volute. The content reflects §2 of that Note at svn revision 2800.