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/
