Skip to content

Schema format validation inconsistencies #1017

Closed
@cdavernas

Description

@cdavernas

What seems off:

Impossibility to consistently validate workflows using the v1.0.0-alpha3 schema due to validation inconsistencies and/or lack of format validation, resulting in multiple schema matches.

What you expected to be:

To properly and consistently validate (valid) workflows against the DSL schema

How to reproduce:

Given a simplified JSON schema:

"$schema": https://json-schema.org/draft/2020-12/schema
"$defs":
  runtimeExpression:
    type: string
    title: RuntimeExpression
    description: A runtime expression.
    pattern: "^\\s*\\$\\{.+\\}\\s*$"
  endpoint:
    title: Endpoint
    description: Represents an endpoint.
    oneOf:
    - "$ref": "#/$defs/runtimeExpression"
    - title: LiteralEndpoint
      type: string
      format: uri-template
    - title: EndpointConfiguration
      type: object
      unevaluatedProperties: false
      properties:
        uri:
          title: EndpointUri
          description: The endpoint's URI.
          oneOf:
          - "$ref": "#/$defs/runtimeExpression"
            title: ExpressionEndpointURI
            description: An expression based endpoint's URI.
          - title: LiteralEndpointURI
            description: The literal endpoint's URI.
            type: string
            format: uri-template
      required:
      - uri
additionalProperties: false
properties:
  address:
    "$ref": "#/$defs/endpoint"
required:
- address

It's impossible to consistently validate the following values, even though they are all supposed to be valid:

address: 'https://www.google.com/'
address: '${ .foobar }'
address: 'https://www.petstore.com/getById/{petId}'
Validator
https://www.google.com/
${ .foobar }
https://www.petstore.com/getById/{petId}
Non URI value
jschon.dev valid invalid valid valid
json-everything.net invalid valid invalid invalid
jsonschemavalidator.net valid valid valid valid

Proposed fix:

Remove the runtimeExpression and all its references from the schema, transforming oneOf alternatives that include it into plain string, formatless properties.

Metadata

Metadata

Labels

area: specChanges in the Specificationchange: breakingA breaking change that will impact in a major version change.change: fixSomething isn't working. Impacts in a minor version change.

Type

No type

Projects

Status

Done

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions