How do we define expected schemaFormat behavior in tooling?

[jonaslagoni]

This issue is triggered by discussion in: #622

How can we define a standard behavior (should we even define it?), to a degree that tooling can understand and implement "expected" behavior?

I.e. if you are a maintainer on a parser, what do you do if you encounter a JSON Schema and a Raml schema that the message can follow? Especially if we talk about a mix such as what @GeraldLoeffler highlights in #622 (comment).

In our JS Parser we handle such different formats, by converting all of them to JSON Schema. However, this is highly up to interpretation as to how to achieve this.

There are no standard conventions, tooling can follow to ensure that users of the spec get the "expected" output.

Related issues

• Clarify what to do if Schema Object contains $schema and message schemaFormat #655

[jonaslagoni]

Maybe this is something for https://github.com/asyncapi/parser-api to define? 🤔

[magicmatatjahu]

To be more specific, do you mean the conventions of how Avro/RAML/etc should be converted to JSON Schema, yes?

[jonaslagoni]

To be more specific, do you mean the conventions of how Avro/RAML/etc should be converted to JSON Schema, yes?

Not necessarily to JSON Schema, but how should tooling handle such logic in general. Should it even be converted to JSON Schema, or should it be something different?

This is especially needed when parsers in multiple languages are needed to ensure consistency between them.

[magicmatatjahu]

Ok, I understand, thanks! Atm ParserJS exactly converts the custom schemas to the AsyncAPI Schema Object (which is superset od JSON Schema, but it's not the same), so maybe we should go with that solution also in other implementations for another languages. However, in order to be consistent, we should have instructions on how to convert a given custom schema into an AsyncAPI Schema Object, i.e. what representation of the Raml, Avro etc keywords should be in the Schema Object - and this is where the parser-api repo would come in handy. Thanks for noticing the problem!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[jonaslagoni]

Still relevant

[magicmatatjahu]

@derberg Could you reopen it?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️