AJV validating URL properties as format `uri-reference`? about openapi-schema-validator HOT 14 CLOSED

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

from openapi-schema-validator.

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

from openapi-schema-validator.

See OAI/OpenAPI-Specification#3235

from openapi-schema-validator.

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

from openapi-schema-validator.

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:

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

3.1 describes it as :

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

from openapi-schema-validator.

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

from openapi-schema-validator.

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

from openapi-schema-validator.

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'

from openapi-schema-validator.

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'

from openapi-schema-validator.

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'

from openapi-schema-validator.

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.

from openapi-schema-validator.

@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

from openapi-schema-validator.

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.

from openapi-schema-validator.

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

from openapi-schema-validator.