You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue #556 proposes an unevaluatedProperties keyword, together with the mechanisms for implementing it. This issue will only be considered if #556 is accepted.
Those same mechanisms (which should be debated in #556, and not here) could be used to define an unevaluatedItems keyword, based on an "evaluatedItems" annotation that is updated whenever "items" or "additionalItems" are successfully applied to an index.
Successful application of schema-form items or additionalItems (alongside the relevant array-form "items") would indicate that all array elements have been evaluated, and the "evaluatedItems" annotation ought to be able to convey that concisely.
additionalItems is used for things like positional function arguments where the first N arguments have specific types or structures, and an indefinite number of further positional arguments are allowed, all with the same type/structure. It's not exactly a common use case, but it is clear and has obvious parallels in numerous programing languages.
unevaluatedItems would be used in some sort of situation where, due to a oneOf or similar construct you will only know at runtime how long the prefix of individually typed elements will be.
As with unevaluatedProperties, unevaluatedItems is mainly useful in very large schemas, or schemas assembled out of many pieces. It is obviously trivial to refactor the schema above to use additionalProperties instead.
We don't have a lot of data on additionalItems and how (or how often) it is used, so it's hard to say how useful unevaluatedItems would be. But, once you're already implementing unevaluatedProperties it's not hard to add this, and the symmetry is appealing.
It would be interesting to find an example of schemas for systems involving complex sequential data.
The text was updated successfully, but these errors were encountered:
Issue #556 proposes an
unevaluatedProperties
keyword, together with the mechanisms for implementing it. This issue will only be considered if #556 is accepted.Those same mechanisms (which should be debated in #556, and not here) could be used to define an
unevaluatedItems
keyword, based on an "evaluatedItems" annotation that is updated whenever "items" or "additionalItems" are successfully applied to an index.Successful application of schema-form
items
oradditionalItems
(alongside the relevant array-form "items") would indicate that all array elements have been evaluated, and the "evaluatedItems" annotation ought to be able to convey that concisely.additionalItems
is used for things like positional function arguments where the first N arguments have specific types or structures, and an indefinite number of further positional arguments are allowed, all with the same type/structure. It's not exactly a common use case, but it is clear and has obvious parallels in numerous programing languages.unevaluatedItems
would be used in some sort of situation where, due to aoneOf
or similar construct you will only know at runtime how long the prefix of individually typed elements will be.As with
unevaluatedProperties
,unevaluatedItems
is mainly useful in very large schemas, or schemas assembled out of many pieces. It is obviously trivial to refactor the schema above to useadditionalProperties
instead.We don't have a lot of data on
additionalItems
and how (or how often) it is used, so it's hard to say how usefulunevaluatedItems
would be. But, once you're already implementingunevaluatedProperties
it's not hard to add this, and the symmetry is appealing.It would be interesting to find an example of schemas for systems involving complex sequential data.
The text was updated successfully, but these errors were encountered: