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

[chromatic]

On Thursday 17 April 2008 15:16:53 Michael G Schwern wrote:

> chromatic wrote:

> > That's my suggestion.  Figure out the minimal set of keys that we expect
> > to use in the near future and reserve those.  Document them.  Suggest
> > that we might add more keys later, if there's a rough consensus and
> > working code. Don't forbid people from adding their own keys, but
> > recommend that they bring them up for public discussion.

> That's the plan.  Official keys will be formalizations of what users do out
> in the real world.  In most cases hopefully just a down-casing.

That part I don't mind.

> We'd like folks to be able to add their own keys as they need without first
> wondering whether it might be useful for others or worrying if we might add
> a key of the same name, but different functionality, later.  Thus the
> separation of local from official keys.

This part I think will not work.  You can't pave the cow paths if you never 
see the pasture, and you can't not break the DarkPAN because the only way to 
know if the DarkPAN even exists is to see if light bends in its vicinity.

Worse, if you make the argument that name collisions are bad, because you 
can't determine programmatically the semantics of a key from the surrounding 
TAP document (and I don't mind this argument; it's a designing principle of 
Roles in Perl 6 for example) as the reason why TAP keys need a separate 
namespace from user-defined keys, you've just moved the problem somewhere 
else.

To wit: what if I use multiple producers/consumers which produce false cognate 
keys?

Solution one: don't try, at least for the general case.  There's TAP keys and 
there's everything else, and if everything else doesn't play together nicely, 
them's the breaks.  You get both pieces.

Solution two: tag every key with an organizational prefix.  This includes TAP 
keys.  Any non-prefixed key is invalid.

Can we enforce solution two?  Not entirely; only as far as producers and 
consumers agree roughly on a version of the TAP spec.  Further, we're pushing 
the namespacing problem in a different direction.  Organizational names may 
conflict.  However, they're less likely to have the false cognate problem.

-- c