On 6/11/2019 7:31 PM, Josh Steadmon wrote:
Define a JSON schema[1] that can be used to validate trace2 event
objects. This can be used to add regression tests to verify that the
event output format does not change unexpectedly.
Two versions of the schema are provided:
* event_schema.json is more permissive. It verifies that all expected
fields are present in each trace event, but it allows traces to have
unexpected additional fields. This allows the schema to be specified
more concisely by factoring out the common fields into a reusable
sub-schema.
* strict_schema.json is more restrictive. It verifies that all expected
fields are present and no unexpected fields are present in each trace
event. Due to this additional restriction, the common fields cannot be
factored out into a re-usable subschema (at least as-of draft-07) [2],
and must be repeated for each event definition.
[...]
+
+ "data-json_event": {
+ "allOf": [
+ { "$ref": "#/definitions/event_common_fields" },
+ {
+ "properties": {
+ "event": { "const": "data-json"
},
+ "repo": { "type": "integer" },
+ "t_abs": { "type": "number" },
+ "t_rel": { "type": "number" },
+ "nesting": { "type": "integer"
},
+ "category": { "type": "string"
},
+ "key": { "type": "string" },
+ "value": true
+ },
+ "required": [
+ "event", "t_abs", "t_rel", "nesting",
"category", "key",
+ "value"
+ ]
+ }
+ ]
+ }
+ },
[...]
Here you have "value" as just a boolean rather than a sub-object.
Is that a limitation of the schema tools? I guess this is reasonable
since the contents of the sub-object are variable and you wouldn't be
able to verify it anyway.
Jeff
