Proposed fixes for the CWL JSON Schema

[sim13pods]

Hi @fmigneault

I was checking out the JSON Schema and noticed a couple of small issues that were causing validation problems. I took the liberty of making a few quick tweaks to fix them, ensuring the Schema now works as expected:

• updated schema to draft 2020-12;
• format: uuid does not need the pattern to be specified;
• format: url replaced with format: uri that does not need pattern to be specified;
• single valued enumerationss converted to constants;
• type: 'null' wrongly interpreted, replaced by type: null
• fixed misaligned required' element in InlineJavascriptRequirement` entity.

Please feel free to review it and let me know what you think. I’m totally open to feedback or further changes if needed.

Thanks a lot for your work on this! It’s always awesome to see well-crafted schemas shared with the community — I truly appreciate your efforts and I just wanted to give something back!

[mr-c]

@sim13pods Any thoughts on the validate_json failure?

[sim13pods]

@sim13pods Any thoughts on the validate_json failure?

@mr-c I will take care of understanding how that specific validation works ASAP, I will update the PR during the next days, thanks for the pointer!

[fmigneault]

enum->const is OK given the schema version change.
It was not allowed in older JSON-schema.

Other specific issues indicated directly in the code.

[fmigneault]

@mr-c @sim13pods

Any thoughts on the validate_json failure?

Amongst other fixes mentioned, because of the fix for InlineJavascriptRequirement, the required: -expressionLib becomes effective. This causes valid definitions InlineJavascriptRequirement: {} to fail.

There might be a need for a separate entry to manage the map/list variants, because while InlineJavascriptRequirement: {} is valid, InlineJavascriptRequirement: [{}] is not (if the object is in a list, that item MUST have the relevant expressionLib).

[mr-c]

expressionLib

is not required, it is optional: https://www.commonwl.org/v1.2/CommandLineTool.html#InlineJavascriptRequirement

[fmigneault]

Yes, but creating a list of InlineJavascriptRequirement: [{}, {}, {}, {}, {}] creates confusion in intent. In JSON schema, we can enforce that omitting the object if nothing is inside is preferred, unless it is directly the object.

[sim13pods]

Hi there @fmigneault I just pushed your suggested changes, I have no idea anyway how to handle InlineJavascriptRequirement issue :(

[fmigneault]

@sim13pods

It would be something similar to this:

cwl-v1.2/json-schema/cwl.yaml

Lines 970 to 991 in ec03f9a

	CWLHints:
	oneOf:
	- $ref: '#/$defs/CWLHintsMap'
	- $ref: '#/$defs/CWLHintsList'
	title: CWLHints
	description: Non-failing additional hints that can help resolve extra requirements.
	CWLHintsMapExtras:
	type: object
	properties:
	BuiltinRequirement:
	$ref: '#/$defs/BuiltinRequirement'
	OGCAPIRequirement:
	$ref: '#/$defs/OGCAPIRequirement'
	WPS1Requirement:
	$ref: '#/$defs/WPS1Requirement'
	additionalProperties:
	$ref: '#/$defs/UnknownRequirement'
	CWLHintsMap:
	title: CWLHintsMap
	anyOf:
	- $ref: '#/$defs/CWLRequirementsMap'
	- $ref: '#/$defs/CWLHintsMapExtras'

The expressionLib requirement would be only under the "item" schema to force it when using the "list" variant, while the "map" variant can be empty.