Avoiding polymorphic values

[stuartpb]

I'm pretty sure the docs reflect this design already, for semi-conscious reasons (like, I think this is something I gravitated to and that older designs were looser about this), but I'll want to verify that there are no polymorphic values as I go into #146 and document the full, proper schema for real.

Why no polymorphic values? Well, because I want any code using these profiles to really only have one branch when it comes to evaluating values: it's either undefined, or it's present, and can be handled as one type - if it's an object or an array, you can jump straight from confirming its presence to testing its children, without having to sniff its type first to make sure you're not going to run into some error that includes the words "attempt to index".

(Also, we don't use null or booleans like false so if whatever can be used to test if a value is present in Lua, and if (whatever) can be used in most cases in other languages that are a bit looser with what they consider falsy. See #96.)

If you know something will always be an array, you can test it with if (whatever.field && whatever.field.indexOf(something)). If it can be something else, you have to start throwing in Array.isArray, or && whatever.field != 'none', or stuff like that. While some languages will always have some amount of type-trickiness (JS, for instance, will have if (whatever.field || whatever.field === 0) wherever a numeric field can hold zero because, unlike Lua, JS considers zero to be falsy), I want to minimize it, especially when there's going to be enough trouble testing for the presence of deeply-nested properties all the way down.

[stuartpb]

Note that this (along with the "no boolean-ish values" thing from #96) should probably bet integrated into the https://github.com/opws/domainprofiles/wiki/Style-Guide at some point (which should itself migrate to whatever repo the schema goes to post-#147).

[stuartpb]

See also #200, which also deals with values that can only mean one thing (ie. that if something is not present, it can only mean it's ambiguously-profiled, and not that it's nonexistent).

[stuartpb]

Also, I think it's worth noting that the schema does have a kind of polymorphism, but only at the property level of objects via duck type (ie. where certain properties are mutually exclusive from others).

[stuartpb]

I think some of this kind of boils down to "the schema will be verifiable with old, pre-anyOf versions of JSON Schema, even though we'll be using anyOf / oneOf to enforce stricter matching anyway", per #146.

[stuartpb]

Closing, pinging opws/opws-guidelines#3.