How should asset processing properties be validated?
l0b0 opened this issue · 1 comments
l0b0 commented
The schema contains the following section:
{
"type": "object",
"$comment": "This validates the fields in Collection Assets, but does not require them.",
"required": [
"assets"
],
"properties": {
"assets": {
"type": "object",
"not": {
"additionalProperties": {
"not": {
"allOf": [
{
"$ref": "#/definitions/require_any_field"
},
{
"$ref": "#/definitions/fields"
}
]
}
}
}
}
}
}
What is the semantics meant to be? Are the not
s actually meant to be there? I would expect the idea is that if there are any assets then any processing properties within them should be valid, not invalid. In code, I'd expect the following test to pass:
it('should fail validation when asset processing expression is invalid', async () => {
// given
example.assets = {
'example': {
'href': 'https://example.org/file.xyz',
'processing:expression': null,
}
};
// when
let valid = validate(example);
// then
expect(valid).toBeFalsy();
expect(
validate.errors.some(
(error) =>
error.instancePath === '/assets/example/processing:expression'
&& error.message === 'must be object',
)
).toBeTruthy();
});
m-mohr commented
The weird "not" validation is a workaround for not having an object-based "contains" in JSON Schema draft 7, see json-schema-org/json-schema-spec#1077 (comment) for details. So if you replace the chained "not" "additionalProperties" "not" with a "contains" (in your mind) it may make more sense. I assume this is solved then? Otherwise, let me know.