Arrays in TAP_SCHEMA

[Markus Demleitner]

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