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

[Michael G Schwern]

chromatic wrote:
>> 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.

I don't understand, what will we break on the DarkPAN?  The whole point of 
separating user from official keys is so we don't break the DarkPAN.


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

Again, I don't understand.


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

Now I really don't understand.  Are you advocating key prefixes per 
organization like "tap.foo" and "xerox.foo" and, dare I delve into Java land, 
"com.google.foo"?


-- 
184. When operating a military vehicle I may *not* attempt something
      “I saw in a cartoon”.
     -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
            http://skippyslist.com/list/