Proposed erratum to clarify arraysize="1"

[Mark Taylor]

On Thu, 15 Feb 2018, Tom Donaldson wrote:

> Mark and all,
> 
> I think the R2 ruling proposal is interesting.  By simply making arraysize=”1” illegal, we would:
> 
> 
> ·         Eliminate the complications of explaining that option in the spec or of interpreting it in clients.
> 
> 
> ·         Possibly be doing what was meant by the original spec anyway (“The arraysize attribute exists when the corresponding table cell contains more than one…”).
> 
> As you say, it has the downside of not supporting 1-element arrays. I admit to feeling a certain appeal in the consistency and completeness of offering 1-element arrays (just as those are available in programming languages), but I can’t think of a specific need, so I won’t push hard either way.
> 
> I do think it’s important that with either R1 or R2, clients should not have to change.  The erratum is just another input to consider when deciding their implementation.
> 
> As a side note, I agree that STIL/TOPCAT does do the sensible thing.  ☺  For astropy however, it’s worth noting that although it treats arraysize=”1” cases as “arrays”, those arrays offer flexibility within the astropy/numpy framework that ends up treating the value as a scalar when one is needed.
> 
> As a simple example, this output:
...

Interesting.  So python-code-using-Astropy generally does the sensible
thing too.

Summarising, it looks to me like R1 (arraysize="1" means it's an array)
is more aesthetically appealing (to Markus's inner mathematician and
the rest of us too), but R2 (arraysize="1" is illegal) makes for more
straightforward explanations and direction to clients.

Either way, I'll do something pretty similar:

   - add a warning to my VOTable validator for arraysize="1"
   - keep TOPCAT behaviour basically the same, but maybe add a log
        message when encountering arraysize="1"

Given all that, I prefer R2, but I can live with either.

Finally, just to follow up an earlier comment of Tom's:

> I may be missing some of the practical reasons why it’s bad to declare
> existing services noncompliant. Although there has historically been a
> stigma attached to noncompliance, that is certainly not an intent here.
> Instead the hope is that noncompliance would be a mechanism for informing
> providers and encouraging change where practical.

I don't forsee real practical issues here.  But I do think that a
stigma does and should associate with non-compliance, otherwise
what's the point of normative text?

and one of Markus's:

On Thu, 15 Feb 2018, Markus Demleitner wrote:

> [1] In case you're looking for a concrete use case: I think a cube
> data model should have the lengths of the array axes denoted
> somewhere, and I'd feel it would be really appropriate to serialise
> these as a VOTable PARAM (proper annotation omitted):
>
>   <PARAM name="axis_length" datatype="integer" arraysize="3"
>     value="1024 1024 300"/>

Arguing against myself, I can think of another: when applied to
datatype="char" (or "unicodeChar") and at least when read into
Java, a character scalar and a 1-element character array have
different obvious representations, namely a char primitive
(or Character object) and a length-1 String, which are quite
different beasts.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/