Document the package.
Change-Id: I770c14d6339b75ea6827280c23171c3584dc1071
Reviewed-on: https://go-review.googlesource.com/c/tools/+/674977
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add additional fields to Schema which are mentioned in the spec but
do not affect validation.
Change-Id: I89488261a00c207d01cd7fc59d782f43692fe528
Reviewed-on: https://go-review.googlesource.com/c/tools/+/674976
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Jonathan Amsterdam <jba@google.com>
A dynamic reference is like a dynamic variable in a programming
language, with two twists:
- There must be a dynamic anchor in lexical scope for the ref to
resolve. (Think of it as declaring the dynamic variable.)
- The ref resolves to the schema highest on the stack, not lowest.
That feels odd, but it turns out to work for the intended purpose,
which is to provide extension points for additional features.
There is some distracting code motion and refactoring in this CL:
resolveRefs was moved down in the file, and resolution of a single
ref was split off.
Change-Id: I17da6052e0782fc540d14b8a41b06a2645923872
Reviewed-on: https://go-review.googlesource.com/c/tools/+/674155
Auto-Submit: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Use pointers for the protocol's struct types, to future-proof against
them getting large.
Change-Id: I55b204080a41c8140539697ba264e502e912e613
Reviewed-on: https://go-review.googlesource.com/c/tools/+/672575
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When we check the root schema during resolution, first make sure
its descendants form a tree.
Change-Id: Icc430e7df463aa84b961c28616be567f98960430
Reviewed-on: https://go-review.googlesource.com/c/tools/+/670776
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Support remote references.
Most of the machinery was in place; we just had to define the
right loader, copy files from the test repo, and download
the meta-schema files from json-schema.org.
Change-Id: Ib588200ef0fa483641b9b53f9904f53b39dc4b82
Reviewed-on: https://go-review.googlesource.com/c/tools/+/670795
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Implement the $ref keyword, except for remote references (those
pointing outside the root schema).
Change-Id: Ia5ca88464e62e9c613970d8d9fcd1512ab288934
Reviewed-on: https://go-review.googlesource.com/c/tools/+/670775
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
s.every now visits the entire subtree of schemas at s, not only the
immediate children of s.
This re-introduces a tower: now of closures instead of iterators.
We could remove it having everyChild call every recursively instead
of returning, just passing f down all the way unwrapped.
But this is going to complicate the recursive function inside
resolveURIs, which needs to pass parent context down. It would have
the same problem that ast.Inspect has, and we'd have to adopt the same
solution, maintaining a stack explicitly.
I feel it's cleaner to keep the recursion simple at the cost of building
several closures. To do otherwise would be premature optimization.
Change-Id: Ic453cdaac482da8147dafc34b0117d25458d1c9d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/670675
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Implement enough of the JSON Pointer spec to suffice for JSON Schema.
For details, see the comment at the top of json_pointer.go.
Change-Id: Ic297f1a1a08903b4b3c6666fe57ac1f45c96c0f7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/670535
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The instance passed to Resolved.Validate can be a struct, or can
contain structs. A struct is treated like the JSON object that it
marshals to.
Also support pointers to any depth. That is, if an instance is a **int,
then Validate will treat it like an int (or nil). That won't happen if
the instance is unmarshaled into an `any`, but may if it's unmarshaled
into a struct.
Change-Id: I39f9af58028bd779887495754519615cd5dfb6c8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/670395
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Assign a base URI to every schema.
See the comment on resolveURIs for details.
Change-Id: I2332d825c486766832503cabdd0bf9d819171d53
Reviewed-on: https://go-review.googlesource.com/c/tools/+/669997
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
The jsonschema package is part of of the API of the mcp package,
so it should not be internal.
Change-Id: I9520797837329fc2cda09c2f46ec4d48d031b9d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/669996
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
