Draft note on STC in the Registry

[Markus Demleitner]

Hi Mark,

On Thu, Jan 25, 2018 at 01:34:51PM +0000, Mark Taylor wrote:
> You suggest in this document using the ASCII serialization mentioned
> (but not presented as a normalised part of the specification) in
> section 3.1 of the MOC 1.0 specification for representing MOC content
> inline in (a) the proposed <spatial> element and (b) VOTable output.
> That would work.
> 
> But for VOTable serialization at least, I think a
> more natural serialization is as an array of integers
> (e.g. <FIELD name="coverage" datatype="int" arraysize="*"/>).
> Using the NUNIQ encoding described in sec 2.3.1 of MOC 1.0,
> a MOC can be represented simply as a sequence of integers
> (>=16-bit for order<=6, >=32-bit for order<=13, >=64-bit for order<=29).

...where 16 bit is not explicitly specified in the current MOC
document, but that could (and probably should) be changed easily.


> In VOTables, an array-valued integer-typed cell can efficiently
> (for BINARY/2 serialization anyway) store MOCs in this form,
> and it should(?) be more straightforward for clients to ingest.

I'm not awfully convinced as regards the compact representation -- the
ranges in ASCII are fairly nifty, and the All-Sky 0/0-11, at least,
is hard to beat.  And either way, I suspect it doesn't buy much
(like: factor of two) in the typical cases, in particular if you gzip
the VOTables.  However, we can just try it of MOCs we find in the
Registry, and I'd do that if there's sufficient interest.

I'd consider the question of straightforwardness in handling much
more insteresting.  For me, where the database (at least for now)
accepts and supplies ASCII MOCs, ASCII is a lot simpler, more
human-readable, and reasonably nice in VOResource, so they appear to
me as more attractive in VOTable as.  But obviously NUNIQ wouldn't
require higher magic, either.

When handling these things from C, I can absolutely believe that
NUNIQ arrays are highly preferable unless you have a nifty and
well-written library.

So, I'm not sure and could be convinced either way.  Whatever we
do, I'd strongly suggest the serialisation should be the (within
reason) the same between VOTable (tabledata) and VOResource.

Since I'd say this needs further discussion and possibly research, in
particular over on Apps, I've put it in as another question to
consider (Volute rev.  4717).

> A suitable xtype would still help with the representation here
> (does that really have to be in DALI?  It seems like sense to
> allow external standards to define their own xtypes, though
> endorsing it in DALI when a new version is being produced would
> be no bad thing).

Well, ideally the VOTable spec will, some day, say where people will
have to look for (non-prefixed) xtypes.  I'd still much prefer if
that was a small set of other specs.  They are adding semantics to
VOTable documents, and most implementors should read such auxiliary
specs if they strive for a "full" VOTable implementation.  So -- I'm
all for "want a new common xtype?  Change DALI".

Thanks,

        Markus