[tap-l] User Supplied YAML Diagnostic Keys: Descriptive Version
Michael G Schwern
schwern at pobox.com
Fri Apr 11 12:01:19 UTC 2008
Here's the descriptive way to specify how the diagnostic keys work.
1) We reserve every key which begins with a lower case letter
2) We say nothing about anything else
3) All keys are optional
That's it. Remember, the only reason we're saying anything about the keys is
because we want to avoid future official keys from clashing with user defined
keys. That is the *only* reason we need to nail this down and it allows us to
say very little.
This makes deciding whether or not something is reserved a simple matter of
running islower() on it in POSIX or Unicode or whatever character set you're
using. Should it become too difficult to nail down what "lower case" means we
can simply reserve [a-z] and say to avoid anything that might be ambiguous.
This also means we don't have to get bogged down in edge cases while still
allowing almost complete freedom of movement for the users. Remember, the
YAML diagnostics are a brand new thing and a huge addition of flexibility to
TAP. People are going to want to do all sorts of wild things with it, let
them. Let's not wall off the playground because someone might skin their knees.
* What about keys with no concept of case? Numbers, asian characters...
They're not lower case, we don't reserve them. Have fun with them.
* What about ambiguously cased words like that Hungarian i thing that comes
out as both upper and lower?
We reserve it because it is lower case, and if you want to shoot yourself in
the foot with ambiguity, or if you're Hungarian, that's fine by me.
* I like using "X-foo" for my custom keys
* I like using "Foo" for my custom keys
Ok, have fun.
* I like writing my custom keys in Klingon!
Ka'plah! Just make sure you don't start it with a lower case Klingon
character and I'll allow you to die with honor.
* What if I want to check that my TAP producer is outputting the right keys?
What if I want to force everyone in my group to write their keys in the same
Write a strict validating parser and use that. We all know it's best to
* What if I want to write my keys in some funky character set?
Go ahead. Nobody else is likely to understand it, but that's ok. They're
your custom keys for your use.
* It's important to me to differentiate between user defined and reserved keys
and I display TAP in a way that doesn't show upper case vs lower case well!
Use a prefix that's not ambiguous to your display. Or pick a better font,
this one is going to cause you all sorts of grief. How are you seeing the
difference between the "have" and "want" value? What about all the other
protocols and languages and commands that are case sensitive?
Stabbing you in the face so you don't have to.
More information about the tap-l