Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How should asset processing properties be validated? #17

Closed
l0b0 opened this issue Dec 14, 2021 · 1 comment · Fixed by #18
Closed

How should asset processing properties be validated? #17

l0b0 opened this issue Dec 14, 2021 · 1 comment · Fixed by #18

Comments

@l0b0
Copy link
Contributor

l0b0 commented Dec 14, 2021

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();
});
@m-mohr
Copy link
Contributor

m-mohr commented Jan 3, 2022

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.

@m-mohr m-mohr closed this as completed Jan 3, 2022
m-mohr added a commit that referenced this issue Jan 3, 2022
@m-mohr m-mohr linked a pull request Jan 3, 2022 that will close this issue
m-mohr added a commit that referenced this issue Jan 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants