List down manual validations

[fmvilas]

The JSON Schema version of the spec is capable of validating many things, however, many others are impossible or very complicated to express. We should carefully read the spec and create a list of all the restrictions/validations that should be applied aside from the JSON Schema ones.

List

• Message examples are valid messages. Not sure if ajv is performing this validation on the schema examples
• Server variable examples are valid according to the schema.
• Operation Ids are unique.
• Check that a server security scheme name matches an object on components/securitySchemes.

[derberg]

Are we doing it in parser or that should go to linters?

channel params is a similar use case that I had with server variables.
Would be good to draw a clear line of what is part of parser validation and what should be implemented separately 😄

Or maybe we should produce some doc that describes all possible validations 🤔 a kind of reference that would be very handy for those that create validators in different languages...

[derberg]

it is related partially to #24

[fmvilas]

Are we doing it in parser or that should go to linters?

I think the case I describe above should be here in the parser but I understand it's a thin line. I think it's wrong to say that there's a parameter but it's not defined anywhere. However, the opposite might be fine for the linter: there's a defined parameter that's not used. What do you think?

Or maybe we should produce some doc that describes all possible validations

You just described the TCK: Give it a try on this branch.

[derberg]

@fmvilas

Message examples are valid messages. Not sure if ajv is performing this validation on the schema examples.

If you mean examples than no, Ajv doesn't want to do it, but it can be done with Ajv plugin, all details here. I did not find any available plugin at the moment.
Knowing that Ajv is now under development to support latest JSON Schema, and it affects Ajv architecture as the plan is to rewrite with TypeScript, I suggest we create a separate issue for it and not in the scope of Parser 1.0 release

Server variable examples are valid according to the schema.

What do you mean by schema? There is no schema for server variables. I don't think we can actually validate those examples really as at the end it is all string

Operation Ids are unique

Check that a server security scheme name matches an object on components/securitySchemes.

I'll work on those 2 but first I need to have #91 merged as this is a first-time manual validation is introduced and I want to be sure this is the way to go

[fmvilas]

I suggest we create a separate issue for it and not in the scope of Parser 1.0 release

👍

What do you mean by schema? There is no schema for server variables. I don't think we can actually validate those examples really as at the end it is all string

Sorry, my fault. However, we can still validate against the enum property if present.

[derberg]

issue for message examples #99
issue for server variables examples #100

[asyncapi-bot]

🎉 This issue has been resolved in version 0.25.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[derberg]

Reopen as we still need to fix Check that a server security scheme name matches an object on components/securitySchemes.

above release just contains Operation Ids are unique. part

[asyncapi-bot]

🎉 This issue has been resolved in version 0.26.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀