not-remove-with-copy.yaml
not-update-with-copy.yaml
not-update-with-remove.yaml
The v1 specification allows update/copy/remove to be in the same action definition even though it's semantically meaningless. It also defines "an order of precedence" of each keyword, which is going to become more difficult to maintain, and understand by readers, as we introduce more keywords.
I propose that we make those mutually exclusive in the language, but also in the schema. Here is the salvaged schema update from my pull request.
action-object:
properties:
target:
type: string
pattern: ^\$
description:
type: string
oneOf:
- properties:
update:
type:
- string
- boolean
- object
- array
- number
- "null"
required:
- update
- properties:
copy:
type: string
required:
- copy
- properties:
remove:
type: boolean
default: false
required:
- remove
required:
- target
$ref: "#/$defs/specification-extensions"
unevaluatedProperties: false
specification-extensions:
patternProperties:
^x-: true
Originally posted by @baywet in #150 (comment)
not-remove-with-copy.yaml
not-update-with-copy.yaml
not-update-with-remove.yaml
The v1 specification allows update/copy/remove to be in the same action definition even though it's semantically meaningless. It also defines "an order of precedence" of each keyword, which is going to become more difficult to maintain, and understand by readers, as we introduce more keywords.
I propose that we make those mutually exclusive in the language, but also in the schema. Here is the salvaged schema update from my pull request.
Originally posted by @baywet in #150 (comment)