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

[Smylers]

Michael G Schwern writes:

> David E. Wheeler wrote:
> 
> > On Apr 18, 2008, at 10:50, chromatic wrote:
> >
> > > My argument was complex: solve the real problem or don't solve it.
> > > The in between position is silly and won't make anyone happy.
> >
> > Yes. The choices, as I see them, are:
> >
> > 1. Do we start out conservative, and loosen things up as the cow
> > paths  indicate (Ovid's position)?

An example of this would be saying:

  We promise that all future 'official' keys will start with a
  lower-case letter.  It is prohibited for you to start an in-house key
  you create with a lower-case letter.

> > 2. Do we start out liberal, allowing anything, and formalize
> > whatever  turns up in the cow paths (what I'm now suggesting)?

An example of this could be saying:

  All current 'official' keys are lower-case (and start with a letter)
  and we expect future ones will be as well.  If you choose to create an
  in-house key which starts with a lower-case letter then you risk a
  clash in future should we happen to introduce a key with that name.

In practice, what's the difference between those two?

The first is apparently stricter, but the prohibition can't actually be
inforced: if a user chooses to ignore it then we can't send him to
prison or anything; it's just that there's a (small) chance of his
system later failing.

Similarly if the future Tap maintainers bizarrely do create a key named
in some other way, whether they are breaking a promise or a mere
expectation doesn't make any difference: it isn't like users can sue
over a broken promise.

So since choice 1 can't be enforced, it seems to behave exactly like
choice 2 anyway.

> The prefixing solution sucks, but it's all we have... and that's a bad
> place to be.  Rather than arguing about a sucky solution, does anyone
> have another solution to offer?

In practice users can name keys however they want.  Namespace clashes
will be a bigger issue for some users than others.  Issue advice on how
to mitigate the problem and let users choose whether to follow it:

  It's possible that a key you pick will also be used by somebody else
  for a different purpose, which could cause problems if your systems
  later get used together.  You can reduce the risk of name clashes by
  starting all your keys with a standard prefix or your organization or
  project name (or something else likely to be unique).

Smylers