Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add support for draft-04 (2019 and 2020 included) json schemas while supporting draft-07 #1006

Conversation

Davidonium
Copy link
Contributor

@Davidonium Davidonium commented Dec 26, 2024

What does this PR do?

Adds support for draft-04, draft-2019-09 and draft-2020-12 json schemas. I first started adding support for draft-04 but some of the changes actually make the code validate the schemas more strictly so I felt the need to add the rest of the drafts. I am not entirely sure of the implications of adding the other drafts which are more complex so I would need some help there testing.

The use of avj-draft-04 is documented here: https://ajv.js.org/json-schema.html#draft-04 so it should not be deprecated or out of support.

According to https://ajv.js.org/api.html#ajv-validateschema-schema-object-boolean using that method should be preferred but I am not sure of the consequences of it.
Citing to avoid having to click there:

Validates schema. This method should be used to validate schemas rather than validate due to the inconsistency of uri format in JSON Schema standard.

What issues does this PR fix or reference?

Is it tested? How?

I added a unit test but I would like to test it in my IDE. I have no idea how to do that so help is more than welcome.

@@ -67,6 +67,50 @@ describe('YAML Schema Service', () => {
expect(schema.schema.type).eqls('array');
});

it('should handle schemas that use draft-04', async () => {
const content = `openapi: "3.0.0"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I specifically wanted to test an openapi v3.0.0 schema because that's what is not working in my IDE.

Comment on lines +103 to +107
service.registerCustomSchemaProvider(() => {
return new Promise<string | string[]>((resolve) => {
resolve('http://fakeschema.faketld');
});
});
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I came up with this to enforce the retrieval of the schema. Not sure if this is the best, feel free to suggest better ways.

@@ -0,0 +1,1662 @@
{
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe having the entire openapi v3.0.0 spec is a bit too much. Let me know if you want me to just use a simple one that uses draft-04.
I used this because it's the use case I wanted to cover (and I think supporting openapi v3.0.0 is very important as there are tools that are unable to upgrade to 3.1).

@Davidonium Davidonium changed the title feat: add support for draft-04 json schemas while supporting draft-07 feat: add support for draft-04 (06, 2019 and 2020 included) json schemas while supporting draft-07 Dec 27, 2024
@HampusHauffman
Copy link

Bump 🥇

@Davidonium
Copy link
Contributor Author

Is there anything I can do to help you all review this one?

@coveralls
Copy link

coveralls commented Jan 21, 2025

Coverage Status

coverage: 84.24% (-0.08%) from 84.321%
when pulling adb309f on Davidonium:add-support-for-draft-04-schemas
into 8a38d41 on redhat-developer:main.

Copy link
Contributor

@msivasubramaniaan msivasubramaniaan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix lint issues

@Davidonium
Copy link
Contributor Author

Davidonium commented Jan 22, 2025

The issue can't be resolved because the bot lint github-advanced-security
is ignoring the rule ignore just above. Running yarn lint-ci is fine locally but that linter is misconfigured.
I tried using es imports and addin json resolution but the umd build then fails because it's not supported.

What can be done to resolve that? It looks like the code that ignored that rule before did not go through the same "external" linting.

@Davidonium Davidonium changed the title feat: add support for draft-04 (06, 2019 and 2020 included) json schemas while supporting draft-07 feat: add support for draft-04 (2019 and 2020 included) json schemas while supporting draft-07 Jan 22, 2025
@Davidonium
Copy link
Contributor Author

I removed support for draft-06 just to avoid the import. I guess if anyone needs support for that will need to deal with the linting issue.

Copy link
Contributor

@msivasubramaniaan msivasubramaniaan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@msivasubramaniaan msivasubramaniaan merged commit 8ebaf45 into redhat-developer:main Feb 6, 2025
4 checks passed
@Davidonium
Copy link
Contributor Author

Thanks for the review!

@lantw44
Copy link

lantw44 commented Mar 10, 2025

It looks like it is broken again in 1.17.0.

@Davidonium
Copy link
Contributor Author

Davidonium commented Mar 12, 2025

This PR was reverted because some users complained about the validation failing when the $schema field starts with https.
Validation failing is techincally correct, as https://json-schema.org/draft-07/schema is a correct URL but not a correct schema identifier. The correct schema identifier for draft-07 is http://json-schema.org/draft-07/schema#.

This can be verified using the following command:

$ curl -fsSL https://json-schema.org/draft-07/schema | jq -r '.["$id"]'
http://json-schema.org/draft-07/schema#

Since this seems to be a source of confusion to users, I guess that a solution could be reached by either not validating the schemas or providing a better error message to convey the above.

Reference on the schema identifier actually being right in this PR:

Issues that cause the PR to be reverted:

@Relequestual
Copy link

This PR was reverted because some users complained about the validation failing when the $schema field starts with https. Validation failing is techincally correct, as https://json-schema.org/draft-07/schema is a correct URL but not a correct schema identifier. The correct schema identifier for draft-07 is http://json-schema.org/draft-07/schema.

This is the correct behaviour. Can you help me understand the decision to revert this PR please?

@Relequestual
Copy link

Relequestual commented Mar 14, 2025

You know, newer modern tooling which does validation using JSON Schema, often will throw an error in such a situation, and not try to download any schems based on the $schema value. Unless they are the meta-schemas, they usually have to be pre-loaded.

As such, I'd argue that by reverting this, you're doing a diservice to users, allowing them to believe that their schema is valid and will work in compliant tooling.

@karenetheridge
Copy link

The canonical metaschema URI is actually http://json-schema.org/draft-07/schema# (with the #).

@Davidonium
Copy link
Contributor Author

Davidonium commented Mar 15, 2025

This is the correct behaviour. Can you help me understand the decision to revert this PR please?

From what I understood, it was reverted from some issues raised in the repo.

The revert happened here:

And it was attempted here:

If you follow through both PRs, these are some of the raised issues:

Just for clarification, I didn't take part in the revert, just explaining what I saw from the outside. I think this PR should be reapplied but I don't call the shots on how the repo is managed.

@msivasubramaniaan Can you help us here?

From what I understand, this is just lack of knowledge (which is understandable) on how the actual schema ids and references work and that there's a difference between where they can be downloaded and how they are referenced.

The canonical metaschema URI is actually http://json-schema.org/draft-07/schema# (with the #).

That's right, I fixed my previous comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants