Ovid wrote: > One issue which arose at YAPC::EU was the problem with machine-readable TAP > diagnostics. > Since they're not yet implemented, we can change them. The problem we wound up with was > that we have two things to specify: core TAP and extended TAP. Core TAP is simple > (well, uh, mostly), but extended TAP is currently envisioned as being YAML > syntax. So > let's look at the YAML spec: > > http://yaml.org/spec/current.html > > First of all, read that thoroughly. That should take you a few days. > > Now let's read the JSON spec: > > http://json.org/. > > Read that thoroughly. That should take you a few minutes. > > JSON is fairly well implemented and new implementations are trivial. This is > not true for YAML. > Trying to define a minimum standard of YAML for extended TAP is a quagmire. With JSON, we can > punt and just point to a fairly well-established JSON spec. > > To be honest, this does not block the IETF proposal at all because we'd > merely be describing the > areas of agreement which need to be reached. However, we do need to discuss this and going from > "I has an implementation" to "I has a spec" is rather like going from "I has Perl" to "I has PPI" > if we stick to YAML.
YAML has several important things that JSON is lacking. With regard to human readability, YAML offers far more flexibility to the TAP producer. A major one being the wrapped scalars. Just have a look at these examples: http://testanything.org/wiki/index.php/YAMLish#Why_not_JSON.3F Human readability of the TAP remains paramount. You always want to be able to interpret test results without having to run them through a parser so you can get fast results without any question of interference by a harness. Simplest case, running a test in a debugger. If all goes well, the YAML diagnostics will take over the need for most human-readable TAP comments. If you recall from Oslo (where did the notes get off to?), the YAML type system solves a number of data formating problems so we don't have to. All JSON has is numbers and Unicode strings. One of the things I recall discussing is how useful this would be for typed languages where it's very important to know the type of a value. YAML types can be little more than local tags which only have meaning to that particular document. name: !customer Evil Business Guy Made Of Butter Or they can be fully formalized. This is how you might formally represent a Java SortedMap object as opposed to any ol hash. %TAG !java! tag:java.yaml.org,2008: --- form: !java!SortedMap - Name: Joe Bloe - Rank: Side Captain - Serial: 123456 The length and complexity of the YAML spec is a red herring. A TAP user will not have to study the YAML spec any more then they will have to study the TAP spec [1]. They are both complex in detail, but the basics are designed to be self-evident. Just as there is a core TAP, there is a core YAML. [2] A TAP producer need not use a full YAML library, they can happily output JSON or even hand roll it. Only a TAP parser need concern itself with having a full YAML library. One of the complexity principles of TAP is to push complexity down from the human and the TAP producer into the TAP parser. There need only be a handful of parsers and there need not be one for each programming language. > And for those who would argue for YAML::Tiny as our spec, it already has > limitations that hit us at the BBC. JSON is a subset of YAML::Tiny, would you have had those problems with JSON? What were the problems? Remember, YAML::Tiny can be extended. JSON can not. In the end, I think this sums it up: JSON doesn't have much in the way of expressibility. YAML has a lot. Pinning the diagnostics to language as narrow as JSON will limit what TAP users can express and how they can express it. This is not good for the Test *Anything* Protocol. The bottom end of TAP spec compliance can be JSON, but the top end has to be YAML or else we're boxing the diagnostics into a corner. The YAML folks have already encountered and thought through many of the data problems we're likely to run into down the line. WRT having something for the TAP spec to point at, there can have various levels of compliance for a TAP parser. RFC 2119 [3] has three levels of compliance, MUST, SHOULD and MAY. This seems to line up nicely with JSON, YAML::Tiny and YAML. :) [1] Or that a Perl programmer needs to study the entire Perl documentation. [2] http://www.yaml.org/refcard.html [3] ftp://ftp.isi.edu/in-notes/rfc2119.txt -- Look at me talking when there's science to do. When I look out there it makes me glad I'm not you. I've experiments to be run. There is research to be done On the people who are still alive. -- Jonathan Coulton, "Still Alive"
