On 7/3/06, Ovid <[EMAIL PROTECTED]> wrote:
Currently, the way that Test::Harness::TAP reads, I should properly discard anything which is not a plan, test or diagnostic output. However, test failure output and programmer supplied diagnostic output need to be disambiguated or diagnostic information is unreliable.
Diagnostic information *is* unreliable in TAP. There is no way in TAP to provide structured diagnostics. None. Zero. All you have is unparsable diagnostics (comments). There is *no format* to those diagnostics. What Test::Builder is outputting is *not reliable*. Do not parse it. A diagnostic format is something which needs to be added to TAP, but nothing currently exists (we tossed around some ideas at YAPC). Do not let this stop you from writing a formal TAP grammar. You can go ahead and spec it out as it currently stands. Writing a TAP diagnostic format is orthoganal to writing a grammar for the current version of TAP.
Also, it's ambiguous from the documentation whether or not whitespace is allowed before the qr/(?:not )ok.*\n/. I think it's implied that no leading whitespace is allowed but that could be incorrect.
Test::Harness does not allow a leading space. There's no reason to start.
Also, regarding directives, the POD shows both "# skip" and "# SKIP". I assume only the latter was intended, but I bet that will break things.
Test::Harness handles directives case insensitively. I don't see any particular reason to stop.
Also, with discussion of upgrades to TAP in the future, unless there's a guarantee that all upgrades will be backwards compatible to the current implementation, we need version numbers in the output. Again, I've not heard any response to this.
We discussed this at YAPC and all agreed: the first extension to TAP should be putting a version number into TAP. About the only other thing we agreed on is that the version should be a simple integer. So the format is open. Since anything not understood is ignored (and I'm liking that feature) we don't have to worry much about backwards compatibility. So probably something as simple as... TAP Version 2 1..2 ok 1 ok 2 though I'm sure there's plenty of proposals floating around out there.
More that one person has expressed interest in a TAP::Parser and all we need is for those officially supporting/maintaining TAP to say "make it so".
What community do you program for? Just do it, man. Get approval / fix it later.
