The paths property pattern is wrong in v3.1

[Gorniaky]

The current pattern is considering any /path entry as an error, when it shouldn't.

[handrews]

@Gorniaky $schema is a JSON Schema keyword, not an OpenAPI Specification field. You cannot use it outside of the Schema Object. The JSON Schema for an OpenAPI Description is implied by the openapi field.

[Gorniaky]

@Gorniaky $schema is a JSON Schema keyword, not an OpenAPI Specification field. You cannot use it outside of the Schema Object. The JSON Schema for an OpenAPI Description is implied by the openapi field.

I use $schema to have autocomplete, but that has nothing to do with the issue.

[handrews]

@Gorniaky regardless of how you are using $schema, what you have posted in this issue is not a valid OpenAPI document, so I don't know how else to address it. We also cannot provide tooling support, so if you expect a specific tool to work with what you have posted, you will need to take that up with your tooling provider.

[Gorniaky]

@Gorniaky regardless of how you are using $schema, what you have posted in this issue is not a valid OpenAPI document, so I don't know how else to address it. We also cannot provide tooling support, so if you expect a specific tool to work with what you have posted, you will need to take that up with your tooling provider.

Is this serious? You didn't even analyze the problem, it's not an external problem, it's within the v3.1 standard that has a bug in the in the paths keyword.

[Gorniaky]

I analyzed the problem, and I came to this conclusion:

If you write other specifications next to the $ref keyword, the $ref keyword overrides the other specifications, causing a bug in the schema.

The patternProperties keyword in #/$defs/specification-extensions overrides the patternProperties keyword in paths.

[Gorniaky]

The most amazing thing is that they wrote this bug in other keywords in the scheme