AJV validating URL properties as format uri-reference?

[MikeRalphson]

See https://github.com/seriousme/openapi-schema-validator/blob/master/test/realworld/failed.md#api-discourselocal-version-latest

The linked schema has no format keyword, but ajv is complaining that servers.url should be a uri-reference. This looks incorrect as the appropriate format would be uri-template (though I'm not sure which Draft of JSON Schema introduced that format value).

[seriousme]

Hi,

I did some research:

There has apparantly been a change between 3.0 and 3.1 of the specification:
3.0 describes it as:

openapi-schema-validator/schemas/v3.0/schema.json

Lines 140 to 148 in a400a7f

	"Server": {
	"type": "object",
	"required": [
	"url"
	],
	"properties": {
	"url": {
	"type": "string"
	},

See also: https://spec.openapis.org/oas/v3.0.3#server-object

3.1 describes it as :

openapi-schema-validator/schemas/v3.1/schema.json

Lines 165 to 172 in d62b397

	"server": {
	"$comment": "https://spec.openapis.org/oas/v3.1.0#server-object",
	"type": "object",
	"properties": {
	"url": {
	"type": "string",
	"format": "uri-reference"
	},

See also: https://spec.openapis.org/oas/v3.1.0#server-object

It seems like the OpenAPI team have decided to apply more strict rules on this object.

And since the spec at https://github.com/APIs-guru/openapi-directory/blob/main/APIs/discourse.local/latest/openapi.yaml starts with openapi: 3.1.0 the test script applies the 3.1 schema.

Looking at the 'blame' of the 3.1 schema: https://github.com/OAI/OpenAPI-Specification/blame/main/schemas/v3.1/schema.json#L171

it seems that this tightening of the rules was introduced by: OAI/OpenAPI-Specification#2586

Hope this helps !

Kind regards,
Hans

[MikeRalphson]

Thanks. failed.md states it is OAS 3.0.3 though...

[seriousme]

Correct, that also surprised me ;-)
It takes the openApi version from: https://api.apis.guru/v2/list.json

  "x-providerName": "discourse.local"
        },
        "updated": "2023-03-06T07:12:59.965Z",
        "swaggerUrl": "https://api.apis.guru/v2/specs/discourse.local/latest/openapi.json",
        "swaggerYamlUrl": "https://api.apis.guru/v2/specs/discourse.local/latest/openapi.yaml",
        "openapiVer": "3.0.3"

Maybe I should have my script double check that ;-)

Kind regards,
Hans

[seriousme]

Ok, just updated my script. It now doesn't take the openapiVer from https://api.apis.guru/v2/list.json anymore but reads the version from the file.

Hope this reduces confusion ;-)

Kind regards,
Hans

[MikeRalphson]

And I've fixed the bug and incorrect metadata on my side.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days'

[MikeRalphson]

See OAI/OpenAPI-Specification#3235

[seriousme]

As soon as the new version is available I will publish a new release. Good to see you fixed it at the source 👍

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days'

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days'

[nielthiart]

A fix for this validation issue was merged two weeks ago, but is yet to be released. This repository builds on the gh-pages branch of OAS instead of main.

[seriousme]

@nielthiart thanks for the tip!

Good to see this one has been adressed. Unfortunately it looks like the YAML file and the JSON file are modified by different PR's so its unclear to me if they represent the same data, can you confirm ?
(I converted the YAML to JSON and ran a diff and got some differences, not sure if they are semanticly different)

The header is still:
`"$id": "https://spec.openapis.org/oas/3.1/schema/2022-10-07",
is this correct?

Kind regards,
Hans

[nielthiart]

Hi Hans, yes it looks like the spec ID hasn't changed, so this update isn't released yet.

In the meanwhile, would you consider accepting a PR that brings this validation library in line with the specification, similar to how you currently replace $dynamicRefs by normal $refs?

The OAS project reminds validation libraries to treat the released text Specification as authoritative in the case of conflicts with the JSON schema:

As a reminder, the JSON Schema is not the source of truth for the Specification. In cases of conflicts between the Specification itself and the JSON Schema, the Specification wins.

The text Specification allows unformatted strings in server URLs, which would validate URLs with template strings in.

[seriousme]

Niel,

I'd rather wait for the official release as it seems nearly ready.
By making a separate copy we might get challenges when other official schema spec changes are released.

If you want to speed things up then getting OAS to publish their new schema seems the best course of action to me.

Kind regards,
Hans