First off, I am pretty much in agreement with chromatic here. What follows is why.
--- chromatic <[EMAIL PROTECTED]> wrote: > > Human readability of the raw diagnostics is important. > > I don't find these big blobs of YAML particularly readable when > compared to the freeform diagnostics we have now. They can be trivially rewritten to any form you want. Because they're YAML, you can do that. > That said, here's a refinement: TAP keys (presumably the most > common keys) don't have prefixes. Other keys do. 80% solution to > readability, and a kind of pressure to TAP producers to standardize > their keys. That satisfies my desire for an 'X-' prefix and limits the problem space to a manageable level, though from chromatic's arguments, I see that this is doesn't solve the 'global namespace' problem. We're effectively using YAML to define an unstructured ontology (and thus, not really an ontology) and without namespaces, meaning is not only ambiguous, but subject to serious bugs. Consider the words 'preservative' and 'preservatif'. They sound similar, but one is English and the other is French. Their meaning is radically different, as discovered by a friend of mine in a horribly embarrassing situation. Java attempted to deal with this with the 'com.foo.bar' syntax. It works reasonably well, though it's limited. Perl 6 has tried a different, more correct, yet heavyweight approach. RDF uses namespaces to unambiguously describe their ontologies. Prolog suffers due to ambiguity inherent in its freeform structure and that's what we're suggesting here? This is a well-known, well-researched problem and trying to be captain of the USS Make Stuff Up means throwing away a lot of research into a fairly well-understood area. I would suggest, like chromatic, that TAP standard keys have no prefix, but that we define a well-understood syntax for unambiguously describing prefixes for user-supplied keys. Sure, we can scrap this and try to keep things simple. Prolog is simple. We see how successful that's been. > In the absence of prefixing, what solves the problem of key collision > between unrelated producers? Nothing. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
