[Ops] Draft concept for standard validator output

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Thu May 12 11:31:21 CEST 2016


Hi Tom,

Thanks for starting this.  But of course, I just have to gripe again.

So,...

On Thu, May 12, 2016 at 03:02:01AM -0400, Tom McGlynn (NASA/GSFC Code 660.1) wrote:
> Attached find a sketch of a possible standard output format for validators.
> It uses a relatively simple but recursive structure to accommodate both

I refer to my personal Gospel, the Zen of python:

  $ python -c "import this" | grep nested
  Flat is better than nested.

For me, this means we should have a strong use case inducing a
requirement for the recursive structure.  And I *believe* the only
one that actually requires the recursive structure *might be* the
"Validation of a set of services" one.  Perhaps we could leave that
out for a while?[1]

> relatively simple validations, e.g., the result of a single IVOID
> validation, more complex validations, like the output from TAPLint, and

I think all of these can be essentially be represented as a sequence
of 

  <test_id>, <test_description>, <test_result>, [<see_also>]

(where <see_also> could be a link to the spec or a page discussing
how to fix things) plus some "global" (e.g., VOTable PARAM)
parameters:

<validator id>, <validator description>, <global result>

with <global result> one of success, warnings, errors (or whatever).

I suspect we should require that <test_id> should be chosen in a way
that sorting by it you get the actual sequence of tests.

The good thing about it is that this is easily represented in a
VOTable, which I'd like a lot: VO places already should have tools to
manipulate them, they have rich, expandable metadata, and once VO-DML
is there, we can still add extra complexity without having to worry
about inventing extra tricks.

So: My proposal would be to define something like the above data
model and say "this is how a VOTable containing this looks like", and
perhaps "this is how it looks like in json" (where I still feel there
should be a canonical mapping from VOTable to json).

Also, I volunteer for setting up an ivoatex document on volute for
this.  Just holler.

Cheers,

     Markus

[1] My suspicion is that the "set of service" use case could be put back
later by adding some sort of container for the individual results, so
even that might work without recursive data.




More information about the ops mailing list