Arrays in TAP_SCHEMA

[Marco Molinaro]

Hi DAL,
I don't think the erratum is a problem.

What Markus proposes as a note to TAP-1.1
and a disclaimer at the end of the erratum
seems reasonable because anyway that
erratum was about "size" and arraysize
usage was later added to tell people
we are working on a solution for the
reserved work clash. But we could have
simply stated that quotes were needed
there and the REC was safe.

So, you have my vote for the proposed
change in TAP-1.1 and I can bring the
Erratum-4 issue to TCG attention to see
what they think about.

Is everybody happy with this?
Are there people against this change
to the arraysize meaning and usage?

Cheers,
    Marco

2017-06-07 9:05 GMT+02:00 Markus Demleitner <msdemlei at ari.uni-heidelberg.de>:
> Hi DAL,
>
> On Tue, Jun 06, 2017 at 02:51:15PM +0100, Mark Taylor wrote:
>> On Thu, 1 Jun 2017, Markus Demleitner wrote:
>> > For 1.1, I don't think we can switch datatype to VOTable types to
>> > complete the transition (or can we?).  But arraysize is new anyway,
>> > and I can't see many reasons to keep the semantics of 1.0 size for
>> > it.
>>
>> Unfortunately, I do see a problem with this.  The recently-accepted
>> TAP-1.0 Erratum 4 (http://wiki.ivoa.net/twiki/bin/view/IVOA/TAP-1_0-Err-4)
>> concerning the size column from TAP_SCHEMA.columns, says this:
>>
>>    To avoid the reserved keyword collision, in the next major version of
>>    TAP, this column will be called arraysize, in next minor revision(s)
>>    the name of the column will be kept for back-compatibility reasons.
>
> Ouch.  I've missed that one -- thanks for pointing this out.
>
>> This seems to say what I had always informally understood, that the
>> TAP-1.1 arraysize column in tap_schema.columns was going to
>> have the same syntax and semantics as the TAP-1.0 size column, but just
>> a different column name to avoid the reserved word collision.
>> That is rather at odds with the suggestion in this thread that
>> arraysize gets VOTable-arraysize-like type/syntax/semantics/capabilities.
>> Given my arguments above, that is a bit of a shame.
>
> Definitely.
>
>> Assuming we do want a VOTable-arraysize like column in TAP_SCHEMA.columns
>> I can think of a few, fairly nasty, options:
>>
>>  - Ignore the size==arraysize implication of the erratum?
>>  - Issue an erratum to the erratum?
>>  - Come up with a name other than arraysize for the VOTABLE-arraysize
>>        column in TAP_SCHEMA.columns, leaving arraysize to do what
>>        size used to do?
>>
>> though maybe I'm missing something.
>
> Unfortunately, I can't see anything you'd be missing.
>
> I guess we could go for the first option arguing we were just
> starting to gain experience with Errata [note to self: be even more
> cautious with preditions about future standards development in the
> future].  If TAP 1.1 said
>
>   This specification disregards the promise in TAP-1.0 Erratum 4 that
>   the arraysize column would be a copy of size.  On reconsideration,
>   it was found that aligning TAP_SCHEMA arraysize with VOTable
>   arraysize was the preferable design.  Given the short time between
>   the acceptance of Erratum 4 and the release of TAP 1.1 working
>   drafts, this seemed to be procedurally acceptable.
>
> I think we'd be marginally fine.
>
> Arguing that we're still gaining experience with Errata, perhaps the
> TCG will let us add an
>
>   Editorial Note: Shortly after acceptance of this erratum, it was
>   discovered that the evolution promise ("To avoid [...]
>   back-compatbility reasons") given here was unwise.  TAP 1.1 will
>   *not* keep this promise.
>
> sentence to http://wiki.ivoa.net/twiki/bin/view/IVOA/TAP-1_0-Err-4?
>
>       -- Markus