Draft note on STC in the Registry

[Mark Taylor]

On Mon, 29 Jan 2018, Markus Demleitner wrote:

> I've put in the somewhat more interesting example
> 
>  <spatial>
>     4/2068 
>     5/8263,8268-8269
>     6/33045-33047,33049,33051,33069,33080-33081,
>     33083,33104-33106,33112,33124-33126,33128-33130
>   </spatial>
> 
> (which, incidentally, is abbreviated from what
> ivo://org.gavo.dc/mcextinct/q/cone has) in Volute rev. 4721.
> 
> For reference, in NUNIQs, this would look like this:
> 
>   <spatial>
>     3092 
>     12364 12365 12359 49488 
>     49489 49490 49429 49430 49431 49496 49433 49435 
>     49508 49509 49510 49512 49513 49514 49453 49464 49465 49467
>   </spatial>
> 
> -- which illustrates that in the typical case, there's not a great
> deal of difference between the representation sizes in VOTable
> TABLEDATA (in BINARY2, as Mark has already pointed out, the second
> form is of course a good deal more compact. But then gzipping the
> entire container will probably nix much of that advantage).

Although I said compactness, I wasn't really thinking of actual
number of bytes, more that a simple list of integers is a very
straightforward representation (given the well-defined NUNIQ coding),
and needs very little in the way of additional arbitrary formatting
conventions (e.g. usage of "/", "-" and "," characters, whitespace
options).  There's not much to go wrong with it.
I know the (currently non-normative) text specifying the ASCII
representation is already written, and I'm not claiming there
are necessarily problems with the current definition, but for
standardised exchange of data my preference is to keep the
representations as clean as possible.

> I'd argue the first form is more human-friendly, the second is more
> machine-friendly, and I'm not sure what that's telling me.
> 
> As an illustration of the human-friendlyness, consider all-sky:
> 
>   0/0-11
> 
> which in NUNIQs is:
> 
>   4 5 6 7 8 9 10 11 12 13 14 15
> 
> If that's part of a large document and happens to be, accidentally or
> by design,
> 
>   4 5 6 7 9 10 11 12 13 14 15
> 
> -- would you have noticed?

Once you get beyond all-sky, I wouldn't have thought there was
much expectation for humans to read and understand these coverage
maps.

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