Introduce data format bindings

[jessemenning]

Background
In contrast to Async communications utilize many different protocols, such as JMS, WebSockets, NATS, etc. But the payload format can be formatted in many different ways as well.

Issue
Similar to protocols, each of these payloads can include different options that are unique to the payload. For instance:

• an XML schema foo.xsd includes multiple root elements. When using foo.xsd to define a message payload format, the developer/code generator needs to be told which root element is being used.
• Protobuf namespaces.
• Others?

While each of these can be specified within the core spec itself, if AsyncAPI includes optional parameters for every potential payload, it will likely be a long list that will not be easily adaptable to the next popular data format.
Proposed Resolution
Similar to protocols, introduce the concept of a payload binding to hold these payload-specific configuration.

[magicmatatjahu]

@jessemenning Thanks for that issue! Maybe we should extend this idea (#622) with adding extra fields to the options next to schema and schemaFormat? The schemaFormat in this case would be the binding name for the format.

Example:

payload:
  schemaFormat: ...xml
  schema: ...xml data
  schemaOptions:
    rootObject: ...
    ... other options

Note that this syntax can be used anywhere in the specification where we can define Schema Object, not just in the message's payload.

Of course we can treat some options as default for every schemaFormat, like ref or resolve:

• ref - reference to the given object with syntax based on the pointer syntax of given format
• resolve - processing the indicated value into a JSON Scheme (as we currently do), or preserving the initial value - needed for Proposal for Unparsable Remote References (mainly to support XML.) #624

schemaOptions will be passed to the given parser for given format.

The difference between protocol bindings and format bindings (schema formats) is that the first are described from the point of view of the app (how server/operation works underneath) and the second from the point of view of the tool, i.e. the custom parser for given format and I think someone might have a problem with that.

What are your thoughts on this?

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