fix: examples of messages should not follow json schema

[derberg]

#370 introduced bug in Message Object JSON schema

examples headers and payload should not follow json schema spec

just like in previous versions these fields need to be flexible as payload or headers are no necessarily json, could be avro for example

noticed with https://github.com/asyncapi/spec/blob/next-major-spec/examples/websocket-gemini.yml

I checked the change locally and works like a charm

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[smoya]

There is something I should be missing because when I read the following in the spec:

• For headers field in message example object:

  The value of this field MUST validate against the Message Object's headers field.

• For payload field in message example object:

  The value of this field MUST validate against the Message Object's payload field.

With that statement, I understand that it should stay as it is, with the anySchema, allowing then any schema (JSON Schema, Avro, etc).
Not sure what I'm missing!

[derberg]

but the spec says map of string and any, so no, it should not stay as it is. As not we expect that in example of the payload, people should provide schema, while it should be an example of payload that is valid with with the schema provided in payload

now, if my payload is

type: string

my example must be

type: string

which makes no sense as I want my example to be

'my example'

[jonaslagoni]

You are right, examples should not have those references 😄

[smoya]

while it should be an example of payload that is valid with with the schema provided in payload

Yeah, that totally makes sense from the usability point of view. I completely misunderstood those statements by thinking they were the same in terms of validation than the object they represent.
If I'm the only one, nothing else to add there, otherwise we could clarify it a bit more on the spec so no one else understands it wrongly as I did.

[smoya]

LGTM! 🚀🌔 Thanks for this catch and thanks for clarifying something might sound obvious 🙌

[derberg]

Thanks @jonaslagoni and @smoya for quick review 🍺

/rtm

[asyncapi-bot]

🎉 This PR is included in version 6.0.0-next-major-spec.10 🎉

The release is available on:

• npm package (@next-major-spec dist-tag)
• GitHub release

Your semantic-release bot 📦🚀