Support of allOf, oneOf or anyOf at payload level

[M3lkior]

Reason/Context

Please try answering few of those questions

• Why we need this improvement?
  Today, it is possible to use those properties at message level but not at payload level
• How will this change help?
  This is useful to set those properties at payload level when the message headers / description / key never change but the payload can
• What is the motivation?
  this is a technical limitation for my enterprise usage. As a workaround i need to create two similar message definitions: one with a null payload and one with a structured payload and use the property at the message level

Description

Please try answering few of those questions

• What changes have to be introduced?
  Support those properties during the parsing of the spec
• Will this be a breaking change?
  No
• How could it be implemented/designed?
  Like we do for the json way
  The implementation must allow to write this kind of definition:

asyncapi: 2.0.0
info:
  title: My API
  version: '1.0.0'
channels:
  mychannel:
    publish:
      message:
        schemaFormat: application/vnd.apache.avro;version=1.9.0
        payload:
          oneOf:
            - type: "null"
            - $ref: 'schemas/Person-1.9.0-namespace.avsc'
        bindings:
          kafka:
            key:
              $ref: 'schemas/Person-1.9.0-namespace.avsc'
          mqtt:
            x-test:
              type: string

[derberg]

at payload level, you can only use oneOf, from the spec point of view

[M3lkior]

hum the others are not supported ? so we can start supporting at least the oneOf keyword in the avro-parser

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

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

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

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

[derberg]

Now when I read this issue for the second time, what do you mean by payload.oneOf? if schema format says Avro, you should have Avro. Does Avro support oneOf and other keywords?

[M3lkior]

at payload level, you can only use oneOf, from the spec point of view

in some case (for example, when a subscribe mode for kafka is RecordNameStrategy ; the topics payload specification can be

asyncapi: 2.0.0
info:
  title: My API
  version: '1.0.0'
channels:
  mychannel:
    publish:
      message:
        schemaFormat: application/vnd.apache.avro;version=1.9.0
        payload:
          allOf:
            - $ref: 'schemas/Person-1.9.0-namespace.avsc'
            -  $ref: 'schemas/Person-2.0.0-namespace.avsc'
     

[derberg]

but payload can only be in a format of given schemaFormat (ignore my previous comment, as I mixed your payload.oneOf with message.oneOf