Information
The json schema is a very useful tool which has matured over time. This would be an intentional effort to close remaining uncontrolled areas so the schema is fully defined in scope.
All objects must declare either additionalProperies: false, or additional properties: true/array of types. The absence of the additionalProperties key would no longer be permitted.
Similar restrictions could be applied to arrays where uniqueItems must be declared as true or false, absence of the key would be prohibited. This ensures the intent of the schema is clear.
Some areas such as items’ customProperties has intentionally open additionalProperties but by declaring the expected type we ensure that the data will be as expected.
In areas such as foundry system definition it may be appropriate to leave the schema open at a high level, but in other area we might identify a gap that could be improved see eg recent improvements in _copy or additionalSpells.
Who would use it?
Correct homebrew would be retrospectively checked and enhanced or coerced into compliance improving data quality.
Future homebrews would have clearer/more complete definition of what data is valid.
The developer may use this as an opportunity for introspection, ensuing completeness and consistency in design intent of data structures, or closing gaps they may have not been aware of.
How would it work?
Ajv does not appear to support this method so via the preprocessor step in the 5eTools-utils npm module
Why should this be added?
Tidy schema tidy mind innit
Upvote - revilowaldow (Lyra)
Upvote - jaredstarwars (Jared Starwars)
Upvote - n1tro_dynamite18 (nitro_dynamite18)
Upvote - teccamtheturtle (Teccam)
Upvote - man3500 (Man3500)
Votes: +5 / -0 / ±0
Information
The json schema is a very useful tool which has matured over time. This would be an intentional effort to close remaining uncontrolled areas so the schema is fully defined in scope.
All objects must declare either additionalProperies: false, or additional properties: true/array of types. The absence of the additionalProperties key would no longer be permitted.
Similar restrictions could be applied to arrays where uniqueItems must be declared as true or false, absence of the key would be prohibited. This ensures the intent of the schema is clear.
Some areas such as items’ customProperties has intentionally open additionalProperties but by declaring the expected type we ensure that the data will be as expected.
In areas such as foundry system definition it may be appropriate to leave the schema open at a high level, but in other area we might identify a gap that could be improved see eg recent improvements in _copy or additionalSpells.
Who would use it?
Correct homebrew would be retrospectively checked and enhanced or coerced into compliance improving data quality.
Future homebrews would have clearer/more complete definition of what data is valid.
The developer may use this as an opportunity for introspection, ensuing completeness and consistency in design intent of data structures, or closing gaps they may have not been aware of.
How would it work?
Ajv does not appear to support this method so via the preprocessor step in the 5eTools-utils npm module
Why should this be added?
Tidy schema tidy mind innit
Votes: +5 / -0 / ±0