Shim layers

[stuartpb]

This is a pattern that's starting to emerge in proposals to annotate how various factors affect or control various aspects of a site's data/operation, like the user being logged in when resetting a password, internationalization (which may skip shims for legal terms), and unusual communication channels for password reset and/or login.

I'm not sure I'm against this mechanism, but I feel like I've unconsciously avoided it up to this point, so I'd like to explore what my thoughts are. It's possible that I've really just been avoiding profiling details that vary to accommodate this.

Some open questions:

• How should shims interact with the "root" object that they shim? Should there be only a shim if it's ambiguous, and then two separate shims contain the different data, and there's nothing on the root? Or should a special-case shim override the values of the root? Should there be another field that denotes that there's an assumption on the root?
• Are there shim-like cases in the current design of the schema? How consistent are they?

[stuartpb]

One thing I remember was being against the idea of having a password.reset.url that might be overridden by a descendant password.reset.flow.request.url. Do shims that are siblings or ancestors (or ancestor-siblings like uncles or cousins) pose different potential issues than ones that are descendants?

Should that be something informing the use of this pattern, per #150, ie. we'll never have descendants shim higher values or vice versa? Or should descendants be used for some cases and ancestors for others, and there's a clear reasoning to that? I feel like that's one of the reasons I've been antsy about this: it makes sense one way, but not the other.

Along those lines: how "standard" should shimming behavior be? Ie, should there be a "this follows the general shimming algorithm" (a la the JSON Merge RFC, ick), or should everything be ad-hoc "This means X if Y is not present overriding it in Z scenario", and we just adhere to a certain set of consistent principles? (My feeling is somewhere between the two: we'll generally follow the same pattern that'll emerge in different places for different stuff, but it won't be codified as a hard-and-fast algorithmic rule. Kind of like how password.value.blacklist and password.contents.whitelist are similar and share some definitions, but there's no strictly-shared concept between the two, nor is there for value-blacklist and contents-whitelist.)

Also note #169 should inform the decisions here (ie. things should be considered in light of "we do or do not want to make this kind of operation generally something you'd use an intermediate interpretation to handle").

[stuartpb]

Like, one thing I want to do with shims is having them defined so that only certain branches of an object representing a shim condition shim something else. For instance, login.email (or wherever the notion of a-login-that-gets-sent-as-a-token-via-email) might have a url, and that should be interpreted as overriding login.url, but it might also have a form, and that doesn't override login.form (it's just a completely different thing).

Also, this covers one of the other things that bug me about shims: the notion of having two things that may have parallel and coincidental similarities, that should not share them. For example, say that, like, instead of having password.reset.flow.change.form and password.change.form, there was some kind of shim for password.change.form that describes what password reset's form looks like (ie. oldpassword.input: none is probably implicitly one, but maybe reset has a repeat.newpassword and change doesn't).