[tap-l] User Supplied YAML Diagnostic Keys: Descriptive Version

[David E. Wheeler]

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