LiteralUri and LiteralUriTemplate patterns are identical, distinction relies on optional format validation

[ricardozanini]

Problem

LiteralUri and LiteralUriTemplate (defined in schema/workflow.yaml under uriTemplate) use the exact same pattern regex. The only distinction between the two anyOf branches is the format keyword (uri-reference vs uri-template).

However, format validation is optional per the JSON Schema specification — many validators treat it as an annotation and don't enforce it. This means implementations that don't enforce format see both branches as identical, making the anyOf distinction meaningless.

anyOf:
  - title: LiteralUriTemplate
    type: string
    format: uri-template
    pattern: "^(?!\\s*\\$\\{)(?=\\S)(([^:/?#]+):)?(//([^/?#\\s]*))?([^?#\\s]*)(\\?([^#\\s]*))?(#(\\S*))?$"
  - title: LiteralUri
    type: string
    format: uri-reference
    pattern: "^(?!\\s*\\$\\{)(?=\\S)(([^:/?#]+):)?(//([^/?#\\s]*))?([^?#\\s]*)(\\?([^#\\s]*))?(#(\\S*))?$"

Proposal

Enforce the distinction directly in the pattern regex so implementations don't need to rely on format validation:

• LiteralUri: reject strings containing { or } (plain URI, no template variables)
• LiteralUriTemplate: require at least one {...} pair (has template variables)

This makes the spec self-sufficient for implementors regardless of their JSON Schema validator's format support.

Context

Introduced by #1169 (which replaced the previous absolute-only patterns with RFC 3986 Appendix B regex). The patterns correctly reject runtime expressions and whitespace, but don't distinguish between the two URI types.

[ricardozanini]

@cdavernas @fjtirado I got this while testing our regexps and thinking about the implementation side. We can keep plain strings and enforce in the regexp. I believe this is simpler and solves the problem once and for all. So we don't rely on format only.

[fjtirado]

@ricardozanini I think, implementation wise, some implementations can rely on format, so I would keep it But, regardless of implementations being able to handle format, providing different regular expressions is also a good idea. So I vote for both approaches, keeping format as it is now (clearly allowing relative uris for literalURI) and adding different regular expressions for templated and not templated uris (I do not know if that is possible, Im pretty clumsy with regular expressions)