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

[chromatic]

On Thursday 17 April 2008 17:56:25 Michael G Schwern wrote:

> We're working around the same issue Perl 5 is having adding new keywords. 
> In Perl 5, since keywords and user-defined subroutines share the same
> space, we can't add a new keyword without risking clashing with a
> user-defined subroutine and giving it new meaning.  Thus the "use feature"
> shame.  By reserving all the lower case keys for official TAP keys and
> leaving everything else for users, TAP is free to add new keys.

Perl 5 also solves the problems of Bob's user-defined subroutines having the 
same name as Chuck's user-defined subroutines.  C doesn't.  C++ does.  PHP 
didn't until (I believe PHP 5.2).  I'm sure you can guess which language 
feature this is.

> We want convergence.  If user defined keys are to have meaning for more
> than just the user or group that defined them, they must converge on a
> common meaning.  User key collisions encourage that.  Users and test
> producer authors can spot the collision and work it out.  Lists of common
> keys and meanings can be published.  TAP displayers can make use of this
> and start to do things with common, user defined keys.

> As the wide-spread utility of a key becomes apparent, they can be lower
> cased and made official.

> It's much like tagging, with most of the chaotic problems and benefits,
> except that there will be a growing set of well-defined, official keys to
> provide some stability.

It didn't work for SMTP headers.  It didn't work for HTTP headers.  Given that 
SMTP and HTTP are somewhat more popular and widespread than TAP, what makes 
you think it will possibly work for TAP?

> 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.

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.

> With readability problems, specification complications and inhibiting
> convergence, prefixing adds more problems than it solves.

In the absence of prefixing, what solves the problem of key collision between 
unrelated producers?  Expecting users to debug these problems and convince 
two or more producers to present their case for convergence to the TAP 
working group in a timely fashion is only one thinly-veiled metaphor about 
banana plantations short of the canonical 20th century Latin American novel.

lo real maravilloso,
-- c