-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cerberus 2: Proposal to clearly distinguish names for different 'schema' rules #385
Labels
Milestone
Comments
note: from an implementation perspective |
i'd say we include proposal 2 in the 1.3 release with the same rationale as here. |
Addressed with #422 |
Closed
implemented in dca2549 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are currently five rules to define constraints on container objects that are either sequences or mappings:
items
defines a sequence of individual sets of rules for each item in a sequencekeyschema
defines one set of rules that all keys of a mapping must matchschema
valueschema
defines one set of rules that all values of a mapping must matchProposal 1
the different meanings of
schema
have been a source of confusion among users and it also forces us to operate with some assumptions in the code and to add some necessary overhead around this.therefore the next major relase should clarify semantics on the
schema
rule. it's quiet obvious that its name points to the first mentioned mapping-related semantic as it matches the overall usage of the term schema in Cerberus' nomenclature.the name of the other rule should be chosen wisely to imply both the similarity with and the difference to the
items
rule.i can think of the following atm:
(see rationale in P2)allitems
(see rationale in P2)eachitem
itemsrules
Proposal 2
as the comprehension above shows, there are two categories of rules in this realm: those that define a set of rules for particular items or just any item of a container object and those that define a schema that assigns such set of rules to values identified by a key. it'd be therefore terminologically stringent to rename
keyschema
andvalueschema
tokeysrules
andvaluesrules
. as there are no name conflicts, the previous names can still be used as aliases.with these terms,
itemsrules
would be a consistent choice for the previous proposal as the morphemeitems
implies that it concerns all of the sequence members and the morphemerules
implies that a set of rules is expected.The text was updated successfully, but these errors were encountered: