Incorrect kafka example (should not be valid)

[insspb]

Describe the bug

This example has x- fields in bindings.

https://github.com/asyncapi/spec/blob/master/examples/adeo-kafka-request-reply-asyncapi.yml

But according to docs they are should not exist there, so example is not valid and should be removed.

https://github.com/asyncapi/bindings/blob/master/kafka/README.md
https://github.com/asyncapi/spec-json-schemas/tree/master/bindings/kafka/0.5.0

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[Sparshagarwal29]

I agree to your point , I took a closer look at the example and the Kafka bindings docs to understand this better.

In the ADEO example, the Kafka bindings include a few x- prefixed fields. From what I can see, the Kafka bindings spec and the 0.5.0 JSON schema are quite strict and say that the binding objects should only contain the properties explicitly defined there.

Because of that, those x-* entries don’t seem to be valid in Kafka bindings, even though extension fields are allowed in other parts of AsyncAPI. This makes the example fail strict schema validation and could be confusing for people who rely on the spec or validation tooling.

So the concern raised here makes sense to me — the example and the bindings spec don’t fully line up at the moment.

[dishantkamble]

Hi, sorry to jump into this issue thread, but i was working on kafka based integration standardization approach in my team, and i was exploring the approach of using extension in the binding for kafka which might be used by internal provisioning team. The approach of using extension fields in binding was more to have the custom details for provisioning of the channel more compartmentalized and not scattered across the spec.

With that context in mind, I am curious to understand where in the binding documentation does it denies using any extensions? If one of you could point me to such a documentation will be helpful for getting clearer understanding on why this becomes an issue, and i could navigate my standardization approach accordingly.

[Ayushkumar242004]

Hi everyone,

I looked into the Kafka bindings schema (0.5.0) and the bindings README. The reason the x-* fields are considered invalid here is that the Kafka binding JSON Schema does not allow additionalProperties, unlike many core AsyncAPI objects which explicitly allow extensions.

Because bindings validation is driven by their individual schemas, extension fields are only valid if the binding schema explicitly allows them. Since Kafka bindings schema is strict, any x-* fields cause the example to fail schema validation.

So technically the example is inconsistent with the Kafka binding spec as published today.

From that perspective, either:

the example should remove the x-* fields, or

the Kafka bindings schema/docs should explicitly allow extensions.

Clarifying which path the maintainers prefer would help decide the correct fix.