Draft note on STC in the Registry

[Markus Demleitner]

Hi Marco,

On Mon, Jan 29, 2018 at 10:43:26AM +0100, Marco Molinaro wrote:
> If possible, can we have a more complex <spatial>
> example in §2.3? Even at this early stage the single
> cell there looks a bit too simple to exemplify what's
> at stake.

You're right -- I hadn't thought of this.

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).

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?

But then: How many people will ever look an serialised MOCs?  And of
course, the "the higher the number, the smaller the area" works as an
eyeball criterion for NUNIQs about as well as a "1/" vs. "18/" might
in ASCII.

        -- Markus