Closed cdavernas closed 1 month ago
@ricardozanini @JBBianchi @matthias-pichler Wanna take a look/kick in before I start the PR?
It's a shame to lose control over the formats, but I agree on the necessity of the proposal, as the validators can't seem to agree on what is what
As discussed in private, +1
@cdavernas I reproduced your results .... firstly I transformed your YAML schema using https://onlineyamltools.com/convert-yaml-to-json
arriving at:
https://www.google.com/ |
${ .foobar } |
https://www.petstore.com/getById/{petId} |
foo |
:&"!§ö |
|
---|---|---|---|---|---|
jschon.dev | ✅ | ❌ (matched uri-template & runtime expression) |
✅ | ✅ | ✅ |
json-everything.net (with "validate format ") |
❌ | ✅ | ❌ | ❌ | ❌ |
jsonschemavalidator.net | ✅ | ✅ | ✅ | ✅ | ❌ |
From the looks of it the main problem does not seem to be the runtime expression regex but rather the implementation of format: uri-template
in different validators.
https://www.google.com/
should be valid against uri-template
in json-everything.net but isn't${ .foobar }
shouldn't match uri-template
in jschon.devhttps://www.petstore.com/getById/{petId}
should be valid against uri-template
in json-everything.net but isn'tIt might make more sense to replace format: uri-template
with a plain type: string
. Optionally we might add a regex such as: https://stackoverflow.com/a/61645285 or https://regex101.com/library/dL2vY6
So my proposed solution might be to use a "custom" uri-template
type, such as:
$schema: https://json-schema.org/draft/2020-12/schema
$defs:
runtimeExpression:
type: string
title: RuntimeExpression
description: A runtime expression.
pattern: "^\\s*\\$\\{.+\\}\\s*$"
uriTemplate:
title: UriTemplate
anyOf:
- title: LiteralUriTemplate
type: string
format: uri-template
pattern: "^http(s?)://.*" # make uris absolute, honestly the only thing that makes sense
- title: LiteralUri
type: string
format: uri
pattern: "^http(s?)://.*" # make uris absolute, honestly the only thing that makes sense
endpoint:
title: Endpoint
description: Represents an endpoint.
oneOf:
- $ref: "#/$defs/runtimeExpression"
- $ref: "#/$defs/uriTemplate"
- 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
this yields the following results:
https://www.google.com/ |
${ .foobar } |
https://www.petstore.com/getById/{petId} |
foo |
:&"!§ö |
|
---|---|---|---|---|---|
jschon.dev | ✅ | ✅ | ✅ | ❌ | ❌ |
json-everything.net (with "validate format ") |
✅ | ✅ | ✅ | ❌ | ❌ |
jsonschemavalidator.net | ✅ | ✅ | ✅ | ❌ | ❌ |
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:
It's impossible to consistently validate the following values, even though they are all supposed to be valid:
valid
invalid
valid
valid
invalid
valid
invalid
invalid
valid
valid
valid
valid
Proposed fix:
Remove the
runtimeExpression
and all its references from the schema, transformingoneOf
alternatives that include it into plainstring
, formatless properties.