PR-TAP-1.1 - Some comments

[Markus Demleitner]

Dear DAL,

I'd like to chime in on two of the issues raised by Gregory:

On Thu, Sep 07, 2017 at 11:36:20AM +0200, Grégory Mantelet wrote:
>     - 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'?

I suppose that's more of a VOTable thing, but I think it would be
great if we could clearly state somewhere that 

  datatype="X" arraysize="1"

is not (or is?) the same as 

  datatype="X"

There are services out there that attach arraysize="1" to any scalar,
which of course leads to interoperability problems.  TAP should then
just say "do it like VOTable does it".

Looking at the whole VO, there are about 60000 columns in GloTS that
currently have size=1 (of a total of about 760000); that's a slightly
different thing, yes, but it illustrates the potential for confusion.

Having clear words here is definitely welcome (and I don't have
strong preferences).


The second point is on that point (and its friends):

>         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.

As the operator of GloTS (where having actual foreign keys *really*
helps keeping the thing clean), can I ask that we explicitly say
"In order to maintain referential integrity, operators are strongly
encouraged to have explicit foreign keys in TAP_SCHEMA as follows:

(TAP_SCHEMA.tables.schema_name) -> (TAP_SCHEMA.schema.schema_name)
(TAP_SCHEMA.columns.table_name) -> (TAP_SCHEMA.tables.table_name)

I'm not so wound up about the following ones:

(TAP_SCHEMA.keys.from_table) -> (TAP_SCHEMA.tables.table_name)
(TAP_SCHEMA.keys.target_table) -> (TAP_SCHEMA.tables.table_name)
(TAP_SCHEMA.key_columns.key_id) -> (TAP_SCHEMA.keys.key_id)

If operators had these in place, I'd have had a lot less headache
about failing harvests.

         -- Markus