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

[chromatic]

On Thursday 17 April 2008 20:21:52 Michael G Schwern wrote:

> chromatic wrote:

> > If TAP v15 adds a
> > new reserved key, anyone who deliberately upgrades may need to modify
> > both the producer and consumer to deal with the collision, if that person
> > even cares.

> I don't understand.  There can be no collision.  Official TAP keys all
> start with a lower case letter.  User defined keys don't.  A new, official
> key cannot collide with anything.
>
> Can you provide an example of your scenario?

1) Suppose that TAP discards this silly idea of namespacing or prefixing or 
reserving a character set subset for reserved keys

2) Suppose that a DarkPAN TAP producer/consumer pair uses a diagnostic key not 
reserved by TAP

3) Suppose that the next version of TAP uses that diagnostic key to mean 
something else

Is this a problem?  No.  As you yourself point out, producer/consumer pairs 
have to upgrade in tandem to process diagnostic keys in a way that's 
semantically correct.

A) If the user does not upgrade to other tools which produce or consume the 
new version of TAP, there's no problem.

B) If the user performs the upgrade and upgrades the DarkPAN producer/consumer 
pair, there's no problem.

C) If the user performs the upgrade and does not upgrade the producer/consumer 
pair, the only problem is that some diagnostic information may display 
incorrectly.  Tests do not fail.  Planes do not fall out of the sky.  You are 
willing to live with this; you said as much in your previous message.

Now replace #1.

1) Suppose that TAP retains the silly idea of namespacing/prefixing/character 
set reserving.

A) If the user does not upgrade, there's no problem.

B) If the user performs the upgrade and upgrades the DarkPAN producer/consumer 
pair, there's no problem.

C) If the user performs the upgrade but does not upgrade the producer/consumer 
pair, the only problem is that some diagnostic information may display 
incorrectly (that is, not at all).  Tests do not fail.  Planes do not fall 
out of the sky.

Thus the silly idea of namespacing/prefixing/character set reserving only 
changes the type of the trivial upgrading problem.

Why?

Because custom diagnostic keys produced by a custom producer need to be 
consumed by a custom consumer.  There is a mutual dependency.

> >> You're either going to wind up with a big list of prefixes and keys,
> >> which is annoying work, or you're going to break down and match on
> >> /-time$/ and defeat the point of prefixing.
> >
> > Every part of customizable diagnostics has this problem.
> Sorry, I don't understand.  Can you provide an example?

If the default behavior of a consumer is to ignore unknown keys, then the 
consumer needs to know which keys it knows.  You're either going to wind up 
with a big list of keys, which is annoying work, or you're going to... well 
okay, you're going to wind up with a big list of keys.

The silly idea of namespacing/prefixing/character set reserving has no bearing 
on this.

> Separating official vs user keys solves a good chunk of the collision
> problem,

It may solve the problem where a collision can occur between official keys and 
a single producer/consumer pair, but that's not actually a problem, and it 
does nothing to solve the problem of collisions between unofficial keys in 
multiple producers, which is much likelier to happen.

Compare the number of TAP producing modules on the CPAN to the number of 
versions of TAP.  There's an order of magnitude difference.  Now imagine that 
half or even a quarter of them decide to use diagnostic keys.

If you really need to solve a collision problem in TAP diagnostics, solve that 
one.  The official/non-official key collision problem is a red herring.

I don't know how to put this any more clearly, so I'm content to let this 
thread die here and watch TAP v15 careen off into crazy town.  (Alternately, 
I could be the one careening off into crazy town, but at the risk of making 
an argument from authority, I *have* written three TAP producers still in use 
today.)

-- c