Replacing "yes" and "no" enums

[stuartpb]

I originally designed the schema so the strings "yes" and "no" are used for fields where a boolean might be used, to leave the door open for non-binary values (eg. password.reset.token.login used to have the values "no", "before", and "after").

However, I'm now not certain that that's a solid strategy: pseudo-boolean values (with values neither "yes" nor "no") just seem like bad solutions.

On the other hand, explicitly checking for "no" beats explicitly checking for false (which can usually be confused for an undefined / nil value). So I'm not fully in one camp or another here.

[stuartpb]

My new belief is that the words "yes" and "no" should generally be avoided, too: more definitively enumerative values, like "accept" and "reject", are better. (Similarly, checked: no should be changed to something like checkbox: unchecked.) They also keep the door open for more enumerative options, as described above, and the "third states" in those cases aren't so egregious. (It also avoids parsing ambiguities with older interpretations of YAML.) Keeping such egregious third-cases out avoids misunderstandings like #4, where the difference between "after" and "no" got lost in the shuffle (and made me think I'd accidentally put "yes" at least once): it keeps meanings from getting overloaded, and other states from seeming like they need to be similarly-boolean.

In any case, yeah, the only falsy value should be the absence of a value, as that allows for cleanly testing whether something has been documented or not.

[stuartpb]

Reviewing the current fields.md, it looks like the only fields doing this (other than login.persist.checked right now) are the "unknown but true" values for captcha fields and password.*.blacklist.previous.

Maybe those should be "custom" and "passwords", respectively (admittedly, an unrecognized CAPTCHA isn't necessarily custom, but that's a job for reviewers to ascertain and fix).

Or maybe the CAPTCHA could just be described better as, like "letters", "numbers", "alphanumeric", "word", "words", "wordoid" (word-like sounds that form a word not in the dictionary), "wordoids", "question" (ie. for when it's just a fixed normal question etc)?

[stuartpb]

What about officially profiling "none"? That's a slightly different, but highly related, issue.

[stuartpb]

There's also password.change.reauth: no, which could maybe be "none" instead?

[stuartpb]

This "there's no such thing as a boolean" design pattern is one of the design patterns in this project that is most directly aped from the CSS world, where almost all values are unique to a specific property.

[stuartpb]

Note that, per #149 (comment), the "no reauth" value will probably become []. Reauth is now an emergent property post-#163.

[stuartpb]

#179 fixed all of the captcha: yes values - now they're all either alphanumeric, letters, or word describing the lingering few that were left.

[stuartpb]

I think the only remaining bool-like value at this point is password.*.blacklist.previous: yes, which... I don't know how to solve more neatly, except maybe for using "some" or "all" as the string instead.

I'm kind of down for changing it to all, because even though that's ludicrous, it states what we're assuming, and it gives editing a definitely wrong value to disprove and correct, instead of making it this ambiguous "hehh... I guess you can't argue with that?" that can never truly be less accurate than a rigorously-tested version.

[stuartpb]

The blacklist problem is going to be solved, under the same logic as what I just described, as password.*.blacklist.previous.period: forever, per #269.

As such, that'll wrap this issue up: all that will be left will be documenting this principle in the schema style guide (#32).