[2.0.0] Circumventing the schema parsing

[jonaslagoni]

Reason/Context

For the message payload, at times it will NOT be desired to convert a different schema format into the SchemaInterface, but rather have access to the raw schema or a specific format to interact with the native format.

In the old API you had message.originalPayload() but that is no longer available.

I also want to question whether the use-case is really there to still keep converting all message payloads into SchemaInterface? What would be the main reason? Abstraction or?

[magicmatatjahu]

If you wanna add new method, you need to update API there https://github.com/asyncapi/parser-api/blob/3a0c511d010c51d8632efb9a74cbfc77244335a7/docs/v1.md#message (you can make suggestion here asyncapi/parser-api#71) and you can create PR with new method. However I think that original() method should be located in the Schema model - see PR asyncapi/spec#797 - so I think that we should wait with adding new methods to the Message model, because probably schemaFormat() will be even deprecated. Also if you want, you can retrieve original payload from the Message's extension:

message.extensions().get('x-parser-original-payload')

I also want to question whether the use-case is really there to still keep converting all message payloads into SchemaInterface? What would be the main reason? Abstraction or?

if you want to use a schema data in an easy way then it's better to have one interface for it - generating models, generating documentation, validating payloads etc is much easier when you base it on JSON Schema and not on a dozen formats. Of course if someone wants to operate on the original format should can, but this is not the most common use case.

[jonaslagoni]

Also if you want, you can retrieve original payload from the Message's extension:

Is that the dereferenced payload model?

if you want to use a schema data in an easy way then it's better to have one interface for it - generating models, generating documentation, validating payloads etc is much easier when you base it on JSON Schema and not on a dozen formats. Of course if someone wants to operate on the original format should can, but this is not the most common use case.

Yea that is true, it does make it easier to work with in the basic use-cases. I can't recall, do you need to provide a schema parser for you to access the raw schema and the parser to work? (I can check later)

[magicmatatjahu]

Is that the dereferenced payload model?

If it's JSON Schema, yes, it is.

Yea that is true, it does make it easier to work with in the basic use-cases. I can't recall, do you need to provide a schema parser for you to access the raw schema and the parser to work? (I can check later)

What do you have in mind? If you have Avro format then you must have a parser given to the parser for Avro schemas, otherwise the parser will throw you an error and the schema is unsupported.

[smoya]

@jonaslagoni is this issue still applying?

[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 ❤️

[smoya]

still relevant IMHO

[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 ❤️