Fix json schemas
Closed this issue · 6 comments
There are a few inconsistencies between json schema and online specification. I suggest to
- general
- make schema draft-06 compliant
- add 'id' and 'descriptions' where applicable
- add 'type' and 'default' for enums
- add 'required' fields where necessary
- make 'additionalProperties': true explicit for 'metaData'
- measurement_schema
- complete 'limits' specification
- add 'patternProperties' and minProperties detail to 'series'
- process_schema
- make 'process' and 'name' of a 'program' mandatory
- fix 'shutoffValues', having properties not items
- fix 'limits', having properties not items and number values rather than object values as limits
- fix 'specialValues' to be an array of specialValue items with 'name' for indicating the nature, rather than one single object with its keys. Offering optional '$_time' tag to be consistent with measurements.
- complete 'series' definition
limits currently have one entry per lower/upper warn/error per measurement point. In the example of
https://www.eclipse.org/unide/specification/#limits_process
it shows an array. So should limits in measurement and process messages be arrays or single values?
I think limits should be single-valued. Do you have use cases that demand multiple limits?
for processes, there might be a different limit in the heating-up phase than for later production phase.
Maybe we keep a limits array as an alternative to one constant value. The former has to be equal length to the corresponding measurements, though. That cannot be checked with schema, but maybe we could cover that with json path or other methods?
No idea, honestly. It feels quite complex. My domain expertise is too limited to assess this properly.
while reviewing the schemas, I also
- sorted the properties for improved readability
- added minItems: 1 to measurement payload / measurements and message payload / messages
schemas updated and refactored to seperate folder: /ppmp/ppmp-schema