On Apr 13, 2008, at 10:41, Michael G Schwern wrote:
Two possible solutions:
A) Just reserve ASCII [a-z]. This is very easy to check for but
I'm worried it's carving out too small a space.
Why would it be too small? I mean, that's a *lot* of words you can use.
B) Reserve "lower case" and leave the spec a little fuzzy around
the edges for the moment.
That seems reasonable to me.
I like B. It gives us some room to move. As demonstrated above,
determining what's user and what's reserved isn't a big deal. The
only reason it exists is so we don't define a standard TAP key that
blows over a user one with a different meaning. For this to happen
because of ambiguity over what is "lower case" requires a double
breakdown:
1) The user has to use an edge case key, which might happen.
2) TAP has to define the same edge case key.
Are we really going to define a standard TAP key starting with a
Hungarian i? Or musical notes? Are we going to provide
standardized keys localized to the user's language? (the displayer
can do that) Not likely.
That's why I suggested lowercase ASCII. Because the use of anything
else is incredibly unlikely. But B seems like a reasonable compromise
to me, and should anything cause a problem in the future (unlikely,
methinks), the spec could always be sharpened by limiting it to
lowercase ASCII or Latin-1.
We don't have to draw the spec with a fine point pen. It's ok to
have some fuzzy bits if we're not sure about it and there's no
serious consequences. Character encoding is one. We have very
little information about how the YAML diagnostics are going to be
used and we know nothing about how they'll interact with alternative
character sets. Let's see what happens and when we know more we'll
draw the lines a little clearer.
+1
Best,
David
