Kafka bindings makes incorrect use of Schema Object

[AgustinBettati]

Describe the bug
Kafka bindings uses Schema Object to define 'groupId', 'clientId', and 'key'. Schema Object is used to define a payload structure, while these facets simply store a string value.

These facets where originally defined as strings, but due to the following issues they where changed to Schema Object:
#21
#22

The concern that was raised in both issues is valid, but the solution was not the correct one. Instead of adjusting the types, the examples should have been fixed.

Expected behavior
'groupId', 'clientId', and 'key' should be defined as strings. Examples must also be adjusted accordingly:

channels:
  user-signedup:
    publish:
      bindings:
        kafka:
          groupId: 'myGroupId'
          clientId: 'myClientId'
          bindingVersion: '0.1.0'

channels:
  test:
    publish:
      message:
        bindings:
          kafka:
            key: 'myKey'
            bindingVersion: '0.1.0'

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue.

Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[fmvilas]

I'm not sure I understand. It looks fine to me. The idea behind these fields being Schema Objects is to be able to apply more complex validation rules. For instance, if I want to apply a rule to all groupIds inside my organization and I don't accept anything that doesn't match the pattern orgName.department.service.version, expressed as ^[\w]+\.[\w]+\.[\w]+\.[\d]+$:

channels:
  user-signedup:
    publish:
      bindings:
        kafka:
          groupId:
            type: string
            pattern: '^[\w]+\.[\w]+\.[\w]+\.[\d]+$'
          bindingVersion: '0.1.0'

[AgustinBettati]

Okay i understand, thanks for the clarification!

[fmvilas]

No problem. Thanks for opening the issue 🙂