[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