search

common-workflow-language / cwl-v1.2

Released CWL v1.2.1 specification
https://www.commonwl.org/v1.2/
Apache License 2.0
33 stars 22 forks source link

Possible invalid SchemaDef reference (?) #251

Closed fmigneault closed 1 year ago

fmigneault commented 1 year ago

While working on https://github.com/opengeospatial/ogcapi-processes/pull/329 I encountered this file which uses SchemaDefRequirement: https://github.com/common-workflow-language/cwl-v1.2/blob/d50fad00eedb071ef7372a0f471e6fc1155addcc/tests/anon_enum_inside_array_inside_schemadef.cwl#L18

Based on other files using similar SchemaDefRequirement, I have seen that the referenced schema from the SchemaDefRequirement to define an input/output's type was refered using #vcf2maf_params instead of plain vcf2maf_params.

Given that the value specified in this case could be interpreted as any CWL Expression ($(...)), is this an actual error for this test sample? Otherwise, how is CWL (or JSON schema validation in my case) supposed to distinguish this from any other plain string? Currently, I'm using pattern (<some-url-pattern>)?#(<some-slug-name) (simplified) to match some URI reference (local or remote).

fmigneault commented 1 year ago

Another similar case: https://github.com/common-workflow-language/cwl-v1.2/blob/d50fad00eedb071ef7372a0f471e6fc1155addcc/tests/record-sd-secondaryFiles.cwl#L18-L20

mr-c commented 1 year ago

While working on opengeospatial/ogcapi-processes#329 I encountered this file which uses SchemaDefRequirement:

https://github.com/common-workflow-language/cwl-v1.2/blob/d50fad00eedb071ef7372a0f471e6fc1155addcc/tests/anon_enum_inside_array_inside_schemadef.cwl#L18

Based on other files using similar SchemaDefRequirement, I have seen that the referenced schema from the SchemaDefRequirement to define an input/output's type was refered using #vcf2maf_params instead of plain vcf2maf_params.

Given that the value specified in this case could be interpreted as any CWL Expression ($(...)), is this an actual error for this test sample?

There is no $( no ${ in the string, therefore that value it can't be a CWL Expression or CWL Parameter Reference. Additionally the type field can never be a CWL Expression: https://www.commonwl.org/v1.2/CommandLineTool.html#CommandInputParameter

Otherwise, how is CWL (or JSON schema validation in my case) supposed to distinguish this from any other plain string? Currently, I'm using pattern (<some-url-pattern>)?#(<some-slug-name) (simplified) to match some URI reference (local or remote).

Identifier resolution is explained at https://www.commonwl.org/v1.2/SchemaSalad.html#Identifier_resolution (referenced from https://www.commonwl.org/v1.2/CommandLineTool.html#Identifiers) For the JSON schema, you could just accept any string.

  • If an identifier URI does not contain a scheme and does not contain # it is a parent relative fragment identifier.
  • If an identifier URI is a parent relative fragment identifier and the base URI does not contain a document fragment, set the document fragment on the base URI.
  • If an identifier URI is a parent relative fragment identifier and the object containing this identifier is assigned to a parent object field defined with subscope in jsonldPredicate, append a slash / to the base URI fragment followed by the value of the parent field subscope. Then append the identifier as described in the next rule.
  • If an identifier URI is a parent relative fragment identifier and the base URI contains a document fragment, append a slash / to the fragment followed by the identifier field to the fragment portion of the base URI