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
In #2064 the protocol extensions extend the base schema. This means that if we combine two extensions together we would run validation rules twice. It could be cleaner if the extensions don't actually $refer to the base schema.
On the other hand, not referring to the base schema means it's not immediately visible that this is meant as an extension. So, we'd lose that explicitness.
For correctness it doesn't matter, running the same validation rules doesn't change the semantics.
For performance it might or might not matter. Validators should/could be optimizing redundant checks away. Using deep stacks allOf and anyOf seems fairly common in schemas. And running 600+ tests runs <1.0s in that PR.
The text was updated successfully, but these errors were encountered:
We could define a schema for the config and asset extensions and then generate the full extension schemas.
Moreover, we could then generate a full schema for all extensions.
#2064 (comment)
In #2064 the protocol extensions extend the base schema. This means that if we combine two extensions together we would run validation rules twice. It could be cleaner if the extensions don't actually
$ref
er to the base schema.On the other hand, not referring to the base schema means it's not immediately visible that this is meant as an extension. So, we'd lose that explicitness.
For correctness it doesn't matter, running the same validation rules doesn't change the semantics.
For performance it might or might not matter. Validators should/could be optimizing redundant checks away. Using deep stacks
allOf
andanyOf
seems fairly common in schemas. And running 600+ tests runs <1.0s in that PR.The text was updated successfully, but these errors were encountered: