Found while closing #162, and deliberately not folded into it: it is the same
class — the exported schema declaring invalid what the engine accepts — with a
different cause.
The finding
A scenario using the templating vocabulary (config + $name, or for-each +
$item) writes a placeholder string where the schema declares a number:
{ "name": "fade_in", "delay": "$delay", "duration": "$d" }The engine substitutes before deserializing, so this is valid input.
rustmotion schema declares delay a number, so a Draft-7 validator rejects it:
'$delay' is not of type 'number'
Measured
Validating the repository's own 14 examples against the schema the CLI exports,
with jsonschema (Draft 7): 62 failing paths, unchanged by #162's alias fix.
Grouping them by their deepest cause:
| Cause |
Paths |
anyOf branch-selection noise (see below) |
57 |
'$delay' / '$d' is not of type 'number' |
5 |
The second half, which is a reporting problem rather than a schema one
Component is a 57-variant tagged enum, so a component that fails for any reason
produces a Draft-7 anyOf failure, and the validator reports whichever branch it
considers most relevant:
'fade_in' is not one of ['fade_in_up']
'card' is not one of ['audio_spectrum']
Neither message names the real problem. A generator reading these cannot act on
them. Worth deciding whether the exported schema should discriminate on type
(if/then or oneOf with a const tag) so a validator can pick the right
branch and report inside it.
Direction
For the placeholders: every field a template can carry has to accept
{ "type": ["number", "string"], "pattern": "^\\$" } — or the schema needs a
TemplateValue union it already has a definition for (ComponentTemplateDef
points at one) applied consistently.
Whether that is worth doing depends on who consumes the exported schema and
whether they are expected to validate a templated file or only an expanded one.
That is the question to settle before writing any of it.
Found while closing #162, and deliberately not folded into it: it is the same
class — the exported schema declaring invalid what the engine accepts — with a
different cause.
The finding
A scenario using the templating vocabulary (
config+$name, orfor-each+$item) writes a placeholder string where the schema declares a number:{ "name": "fade_in", "delay": "$delay", "duration": "$d" }The engine substitutes before deserializing, so this is valid input.
rustmotion schemadeclaresdelayanumber, so a Draft-7 validator rejects it:Measured
Validating the repository's own 14 examples against the schema the CLI exports,
with
jsonschema(Draft 7): 62 failing paths, unchanged by #162's alias fix.Grouping them by their deepest cause:
anyOfbranch-selection noise (see below)'$delay' / '$d' is not of type 'number'The second half, which is a reporting problem rather than a schema one
Componentis a 57-variant tagged enum, so a component that fails for any reasonproduces a Draft-7
anyOffailure, and the validator reports whichever branch itconsiders most relevant:
Neither message names the real problem. A generator reading these cannot act on
them. Worth deciding whether the exported schema should discriminate on
type(
if/thenoroneOfwith aconsttag) so a validator can pick the rightbranch and report inside it.
Direction
For the placeholders: every field a template can carry has to accept
{ "type": ["number", "string"], "pattern": "^\\$" }— or the schema needs aTemplateValueunion it already has a definition for (ComponentTemplateDefpoints at one) applied consistently.
Whether that is worth doing depends on who consumes the exported schema and
whether they are expected to validate a templated file or only an expanded one.
That is the question to settle before writing any of it.