Time Series Cube DM - IVOA Note

[Pierre Fernique]

Hi Mark,

If you are catching my main point, it is the more important.  The 
VOTable parser was an example. And I have to apologize: STILTS is 
indubitably a counter example of a partial implementation. But in my 
knowledge, the list of other VOTable 1.3 compatible libs is not so 
large, or ? And if I have no lib available for my development context 
(UWS, VOSpace, ADQL parser...), the entry ticket is expensive, and, I 
believe, more expensive than before. The level of this effort is, for 
me,  a important criteria for knowing if such of such IVOA standard has 
a chance to be widely used or if it has no chance to be really used a day.

For me the question is always, do we really need to describe such a 
complexity ? And if yes, what is its cost ? Do we think that the future 
clients will be ready to do this effort ?

In any case, thanks to correct me on STILTS and VOTable 1.3 release date.

Cheers
Pierre


Le 03/04/2017 à 11:47, Mark Taylor a écrit :
> 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/