Time Series Cube DM - IVOA Note

[Mark Taylor]

Pierre,

I'm not necessarily disagreeing with your main point, but on the
particular topic of VOTable parsers:

On Mon, 3 Apr 2017, Pierre Fernique wrote:

> Additionally, good dedicated libraries are not so easy to find. If you just
> consider VOTable, this standard is became really complex - probably too
> complex for most of clients (multi RESOURCE, GROUP/ref, BINARY2, FITS stream,
> base64-UTF16, remote data with expiration date...), and it is difficult
> (impossible?) to find a parser/lib supporting all features described in the
> last specification even after 8 years (VOTable 1.3 has been released in 2009).

I would claim that the VOTable parser in STIL
(http://www.starlink.ac.uk/stil/sun252/votable.html)
is, and has been for most of its 14-year history, pretty complete.
It supports all defined VOTable encodings (TABLEDATA, inline or href
BINARY, FITS, and since VOTable 1.3 BINARY2), can read and write
XML text and base64 inline data in any XML encoding in all common
XML encodings (including UTF16) and provides efficient SAX- or
DOM-based access to arbitrary hierarchical structure of VOTable
documents, including ones with very large data payloads.
Note not all of this functionality (in particular preserving
the metadata hierarchy) is exposed in TOPCAT and (most of) STILTS,
which are not intended as VOTable manipulation packages as such.
It's true that STIL doesn't do anything particular with expiration dates
of remote data, but I'd argue that's a job for client sofware
rather than the format access library (and probably this feature
has never been used by data anyway - which is perhaps part of the
point you wanted to make).

BTW VOTable 1.3 was dated 2013, VOTable 1.2 was 2009.

> And for instance, recent Astropy VOTable parser does not manage (crash) GROUP
> tag yet. May be, we want to put too many things in this protocol (and VODML
> future additions are not yet arrived). If the complexity of VOTable is still
> increasing, the real risk is to see appear a simpler JSON alternative
> definitively easier to implement for the client - but that's also meaning that
> we will lost all the benefits of the VO metadata agreements that VOTable had
> successfully provided inside IVOA since 15 years.

Is the complexity of VOTable still increasing?  The standard itself
hasn't changed all that much since VOTable 1.1 in 2004.  Is there
a major revision being proposed?  Of course that doesn't mean that
people can't or don't use the format in complex ways, but they
could do the same with a JSON replacement.

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/