Proposal: Excluding Unmatched Member Names

[anewton1998]

Exclude Matched Member Names

This is a proposal for an algorithm to achieve similar goals as Augmented OR (AOR). These goals modify the current Inclusive OR (IOR) behavior of object rules during validation of objects in the following way:

1. For any choice between two or more members, validation fails if more than one member by name is present in the object.
2. Unless otherwise disallowed by another mechanism, members not specified in the rule should be allowed.

Item 1 is the basic behavior sought by both this proposal and AOR, and gives object rules a quasi Exclusive OR (EOR) behavior where the exclusion is based only on member names and not on the entire evaluation of the member rule (i.e. annotations, name matching and value matching). Item 2 preserves the ability to extend objects in the future.

To achieve these goals, the following is proposed:

1. Object evaluation against object rules changes in the manner specified below if an object has the @{ex} annotation.
2. During the validation of objects, a list of members positively referenced from the object and for which complete member validation did not succeed is kept. That is, if the code looks at member "x", "x" exists in the object, and the evaluation of the member rule that caused it to look at "x" does not fully validate, then "x" is added to the list.
3. For any choice expression, once any member rule in that choice passes validation, all other member rules cannot pass validation. This limits the number of member rules in a choice that will pass validation to 1. Note that rules are still evaluated from left to right as per the current JCR specification.
4. After evaluation of all rules of the object rule, if the list of referenced members is not empty then the object under evaluation fails validation subject to the processing of other annotations (e.g. the @{not} annotation).

Given the following example:

@{ex}{ "a":string | "b":integer }

These objects will validate

• {"a":"foo"} - "a" does not get on the list because it validates to true
• {"b":2} - "b" does not get on the list because it validates to true
• {"b":2, "c":2} - "b" is not on the list because it validates to true, and "c" is not on the list because not member rule would cause it to be reference.

These objects will not validate

• {"a":"foo", "b":2} - "b" ends up on the list because "a" validated to true therefore causing all other member rules in the choice to fail validation
• {"a":2 , "b":2} - "a" ends up on the list because while the member rule was false (2 is not a string), "a" was referenced.

Without the @{ex} annotation, the method given in the JCR specification to "close off" an object (disallow unknown members) is to use the following as the last rule: @{not} // : any +. As in:

{ "foo" : 1, "bar" : 2, @{not} // : any + }

The @{ex} annotation does not change that.