arraysize="1" returns to cause trouble

[Markus Demleitner]

Hi Pat,

On Mon, Mar 04, 2019 at 03:27:49PM -0800, Patrick Dowler wrote:
> On Thu, 27 Sep 2018 at 10:45, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> 
> >
> > An erratum for VOTable gives some advice on the use and meaning of
> > arraysize="1" (link:
> > http://wiki.ivoa.net/twiki/bin/view/IVOA/VOTable-1_3-Err-3). However,
> > this conflicts with something in the VODataService-1.2 xsd (line 949-ish),
> > where the arraysize atrtibute in DataType specifies default="1" and the
> > documentation says that means scalar.
> >
> > I consider default attribute values in xsd to be really sketchy because
> > you cannot round-trip otherwise valid documents and behaviour changes if
> > schema validation is enabled.
> >
> > When I read the xml output from a VOSI tables resource I get arraysize="1"
> > even if the xml itself omitted the arraysize (which is what my TAP services
> > are doing). The VOSI-tables and VOTable documents are no longer always
> > consistent :-(
> >
> > Could that default="1" be removed via an erratum?

Whops, sorry, forgot about that one, too.

First, in the current VODataService 1.2 draft
(https://volute.g-vo.org/svn/trunk/projects/registry/VODataService,
changed in rev. 5151 of on 2019-09-28), the default is already
removed.  Here's what the annotation in the current WD says:

   Leave arraysize empty for scalar values.  In version 1.1,
   this defaulted to 1, which was intended to indicate
   a scalar.  This is now deprecated; an arraysize of 1 should
   be avoided now, the future interpretation, in accord with
   VOTable, will be “array of size 1”.

I suppose that could (perhaps after taking out a bit of
breathlessness) be straightforwardly backported to VODataService 1.1
in an erratum.  Eyeballing the document, changes would propagate to
about five places in the prose (and a few more if we wanted to fix
some language on @delim that will become confusing with this change).
Not pretty, but doable.

I'd reluctantly write the erratum if asked to do so.  As an
alternative, I'd offer to have a PR of VODataService 1.2 by Paris,
now that it seems that there's no great interest in rich column
metadata in the community.  I suppose that we *could* have sufficient
implemenation by Groningen to make it REC then.

Or... what about a deal?  I'll write the erratum for at least one
promise to do reference implementations of the new VODataService 1.2
features before Groningen.  Who's in?

          -- Markus