Section 4.2 - Policy type combinations says this about
value which implies that when parsing the JSON object for a policy metadata the order of the members must be kept in order to know which policy operations appear before
value and which after it:
Can be combined with one_of, subset_of and superset_of. Here the order matters. If value appear in a superiors policy statement then the others MUST be ignored. If value are defined by the subordinate then it MUST be a subset of subset_of, superset of superset_of and one of one_of.
This somewhat contradicts the JSON RFC which says
An object is an unordered collection of zero or more name/value
pairs, where a name is a string and a value is a string, number,
boolean, null, object, or array.
Here I see two possible solutions:
- Add a note to implementers to use such JSON object parsing that the ordering of the members is preserved.
- Modify the spec for combinations with
valueso that the validation / the actions taken need not rely on the ordering of the statements for a given parameter. The action of
valueis to force the parameter to be set to some value, which makes any other statements about the parameter redundant. My suggestion therefore is to simplify the spec and say that
valuemust not be combined with other policy types, i.e. raise an error if this condition is detected.