--- Steffen Schwigon <[EMAIL PROTECTED]> wrote:
> A see. But TAP isn't SMTP or HTTP and an explicit prefix matches the
> "be descriptive" of Schwern, doesn't it?
>
> And we are talking about the diagnostics part, which is primarily for
> the user, so the rules are reversed there.
There are two goals we want:
1. Make it as human-readable as possible.
2. Maximize flexibility.
As for human-readable, consider these:
results:
tap-have: 4
tap-want: 5
results:
have: 4
want: 5
(And remember that there could be plenty of other diagnostics in
there).
I think the second is more readable, but that's a bit subjective.
Still, the idea has merit because it addresses my concern below.
Regarding maximum flexibility, Adrian Howard has already pointed out
that if we restrict people to 'X-', then we can always be more
permissive in the future. If we open it up to just about anything they
want and it turns out to be a mistake, we could easily be backed into a
corner. Why on earth would we *deliberately* choose an option that we
know might be problematic, particularly when someone's non-unicode
aware language might get confused about what is and isn't lower-case?
It doesn't hurt us to play it safe with such a major change. It
*might* hurt us to make a major change when we already KNOW that
potential problems are out there. We're not talking about a minor
utility that only a handful of people would use. We're talking about
playing fast and loose with core infrastructure tool that many people
are dependent on.
On an implementation detail, parsers will need to differentiate between
TAP standard keys an user-supplied keys. Right now it's simple in
Perl:
if ( $key =~ /^[[:lower:]]/ ) {
# internal key
}
Not all languages make it that easy. Also -- I don't know the
specifics here -- are we now going to have to require 'encoding'
meta-information in TAP to make sure that the above regex works?
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/
