feat: enable extensions in bindings

[derberg]

Related asyncapi/spec#893

This PR once and for all makes it clear that bindings are also extendable like other parts of AsyncAPI spec with specification extensions (x-whatever)

• this PR updates all bindings with info about specification extension
• this PR bumps versions of bindings and update their schemas

---

One open questions, something maybe controversial

In this PR I also suggest that text:

This object MUST NOT contain any properties. Its name is reserved for future use.

is replaced everywhere with:

This object does not contain any fixed fields. Its name is reserved for future use.

This object MAY be extended with [Specification Extensions](https://github.com/asyncapi/spec/blob/master/spec/asyncapi.md#specification-extensions).

The fact that we do not have any fixed fields for some binding should not block users from experimenting with extensions. So above change is needed if we want to truly enable extensions in all the bindings.
This change is visible in this commit. I did not provide schemas for these bindings yet, as first I want to be sure it is widely accepted.

[VisualBean]

Why are the versions changing for the Json schemas, but nothing actually changed in them?
I believe most, if not all, already had the extension regex.

[derberg]

@VisualBean yes, you are right, we had extensions enabled on JSON Schema level. But readme text was saying something different. JSON Schema is considered to be a "tool" helpful for validation and other stuff. Individual binding readme is what is the "truth", so if we make some changes there that change behaviour, we need to bump the version of the binding. And yeah, texts in readmes were saying that basically "no props" should be added (which also includes extension).

Does that make sense?

[VisualBean]

@VisualBean yes, you are right, we had extensions enabled on JSON Schema level. But readme text was saying something different. JSON Schema is considered to be a "tool" helpful for validation and other stuff. Individual binding readme is what is the "truth", so if we make some changes there that change behaviour, we need to bump the version of the binding. And yeah, texts in readmes were saying that basically "no props" should be added (which also includes extension).

Does that make sense?

I'm surprised that the "text" side of the documentation is what is considered the "truth" - with that in mind, the change makes sense.

[derberg]

@VisualBean yes, mainly because not all the things can be described with JSON Schema.

It is the same with main spec.

• this is source of truth https://github.com/asyncapi/spec/blob/master/spec/asyncapi.md
• this is just a helper tool https://github.com/asyncapi/spec-json-schemas/blob/master/schemas/2.5.0.json

this is why also binding's JSON Schema files will be also moved to spec-json-schemas repo -> #113

---

Thanks so much for the approval and quick reaction 🙇

[VisualBean]

@VisualBean yes, mainly because not all the things can be described with JSON Schema.

It is the same with main spec.

• this is source of truth https://github.com/asyncapi/spec/blob/master/spec/asyncapi.md
• this is just a helper tool https://github.com/asyncapi/spec-json-schemas/blob/master/schemas/2.5.0.json

this is why also binding's JSON Schema files will be also moved to spec-json-schemas repo -> #113

---

Thanks so much for the approval and quick reaction 🙇

Any time. I think my reason for thinking it was the schema that was the truth, is that it is machine verifiable, so to speak, where the "text" isn't.

Anyway, you are very welcome.

[KhudaDad414]

LGTM!

[CameronRushton]

Solace stuff looks good to me. Thanks!

[GeraldLoeffler]

reviewed and approved anypointmq binding

[dalelane]

makes sense to me 👍

[char0n]

The fact that we do not have any fixed fields for some binding should not block users from experimenting with extensions. So above change is needed if we want to truly enable extensions in all the bindings.

Amen ;]

LGTM and nice work! 🎉

The sentence This object MAY be extended with [Specification Extensions](https://github.com/asyncapi/spec/blob/master/spec/asyncapi.md#specification-extensions) is always in right place, right under the list of fixed fields (if they exists).

[derberg]

only few of you left to accept 😄

@whitlockjc @fmvilas @smoya @lbroudoux @damaru-inc

[whitlockjc]

👍 for googlepubsub.

[derberg]

@lbroudoux @fmvilas @smoya need your approval folks

[smoya]

LGTM! 🚀🌔

[lbroudoux]

Kafka part looks good 🚀

[fmvilas]

@derberg I think we can merge this now, right?

[github-actions]

This pull request 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 pull request, add a comment with detailed explanation.

There can be many reasons why some specific pull request 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 pull request forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️