[Ops] Draft concept for standard validator output

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Thu May 12 14:10:56 CEST 2016


Hi all,

On Thu, May 12, 2016 at 01:42:47PM +0200, Mark Taylor wrote:
> On Thu, 12 May 2016, Markus Demleitner wrote:
> > 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).
> 
> The <test-id>,<test-description>,<test-result>}[] model doesn't fit
> too well with the way that I write validators.
> I don't really think in terms of testing a feature,
> determining pass/fail, and moving on.  Instead I hit the service
> in whatever ways I can think of, look for failures or anomalies,
> and report them.

Right -- this was essentially what I had in mind.  So, rows would
only be shown if <test_result> is an error or a warning, at least by
default (perhaps one could recommend a parameter VERB, with VERB=0
meaning only errors are shown, VERB=5 errors and warnings, VERB=10
successes, too?).

So,

>    message-type (info, error, warning, ...)
>    message-ID (implementation specific, some repeatable tag)
>    message-text (human-readable, free-form)
>    see-also (structured? pointer to standard name, version?, section?)

is essentially what I'd like.  The global PARAMs I think I'd still
prefer to see in.

Cheers,

        Markus


More information about the ops mailing list