stac-extensions/processing

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 nots 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();
});

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.