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
If "items" is an array of schemas, validation succeeds if each element of the instance validates against the schema at the same position, if any.
That means that the above JSON schema should be considered valid against not only ["a", "b", "c"] but also ["a", "b", "c", true] (the list should be open) and also [], ["a"] and ["a", "b"] (any prefix of the "items" array can match).
What did you see instead?
> exec cue def -l '#S:' -p main -o schema.cue schema.json
> exec cat schema.cue
[stdout]
package main
#S: {
@jsonschema(schema="https://json-schema.org/draft/2019-09/schema")
["a", "b", "c"]
}
> exec cue vet
[stderr]
tests.0: incompatible list lengths (0 and 3)
tests.1: incompatible list lengths (1 and 3)
tests.2: incompatible list lengths (2 and 3)
tests.4: incompatible list lengths (3 and 4)
[exit status 1]
FAIL: x.txtar:3: unexpected command failure
Currently there is no nice way to encode this kind of constraint. The query proposal (#165) might help here (see specifically the "Integers in label expressions" section in that issue).
The text was updated successfully, but these errors were encountered:
There are a number of outstanding issues with the treatment
of arrays in encoding/jsonschema.
- it's sensitive to field ordering (#3544)
- it doesn't allow arrays shorter than the explicit number of items (#3485)
- it produces a closed list when it should not (#3432)
We also do not implement the correct semantics for the 2020-12 version
of JSON Schema, which drops support for `additionalItems`
and introduces `prefixItems` instead of the list form of `items`.
This CL fixes the above issues except for #3485, which will
need some other language primitive or `list` package function.
Also in passing, fix the regression-test checking logic so that
it works correctly.
Fixes#3544Fixes#3432
Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I790f734fd657864faf379a9a0f7b920f5e292440
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1203479
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
What version of CUE are you using (
cue version
)?Does this issue reproduce with the latest stable release?
Yes (v0.10.0)
What did you do?
What did you expect to see?
A passing test. The spec says this:
What did you see instead?
Currently there is no nice way to encode this kind of constraint. The query proposal (#165) might help here (see specifically the "Integers in label expressions" section in that issue).
The text was updated successfully, but these errors were encountered: