Ovid <[EMAIL PROTECTED]> writes: > --- Steffen Schwigon <[EMAIL PROTECTED]> wrote: > >> Then maybe I haven't understood what the standardization of >> diagnostics is about. >> >> I thought it is primarily meant for the *user* of TAP to transport >> its own diagnostics of its own test runs and test results? >> >> I for instance would use it to transport benchmark results inside >> tests. > > And that's fine. You can extend it for any use you like. However, > because diagnostics are currently free-form, it's almost impossible to > do anything *programmatic* with them. So, for example, consider sample > output from Test::Differences: > > not ok 1 - lang is respected > # Failed test 'lang is respected' > # at lang.t line 23 > # +----+-----+----------+ > # | Elt|Got |Expected | > # +----+-----+----------+ > # * 0|uno |one * > # * 1|dos |two * > # +----+-----+----------+ > > Well, that seems fine, but imagine that you have test tool which wants > to automatically jump to the file and line number (or auto-navigate you > through a stack trace). We have to *guarantee* that this format never > changes. Ever worked with a test suite where a bunch of tests failed > because someone corrected the spelling in a 'die' message or > localization breaks your hard-coded string matching? By offering a > well-defined syntax, we can alleviate much of this sort of pain. The > above might well translate to this: > > --- > file: lang.t > line: 23 > results: > have: > - uno > - dos > want: > - one > - two > name: lang is respected > display: | > +----+-----+----------+ > | Elt|Got |Expected | > +----+-----+----------+ > * 0|uno |one * > * 1|dos |two * > +----+-----+----------+ > > Then all which really needs to be done is to ensure that your > particular TAP consumer knows what to do with it. In fact, it would be > trivial to simply transform that back to the unstructured diagnostics > we are familiar with.
Thank you. I believe, I understand the example and the need to structure the diagnostics. Now, what, in your example, are the keys you want to standardize/reserve for tap specific purposes? IMHO all keys (file, line, results, have, want, name, display) are specific to Test::Differences. You probably don't want to standardize them, or do you? I think it's quite rare to have keys that are really specific to TAP (not to TAP producers). That's why I think the horror scenario of "tap-prefixes everywhere" doesn't really apply, therefore it's ok to have a prefix "tap-" as the "namespace" of such fields, instead of a huge overkill "all ascii characters belong to us". Steffen -- Steffen Schwigon <[EMAIL PROTECTED]> Dresden Perl Mongers <http://dresden-pm.org/> Deutscher Perl-Workshop <http://www.perl-workshop.de/>
