Sergio Moya

> https://github.com/asyncapi/spec/tree/1.2.0#baseTopicString It is a combination of https://github.com/asyncapi/spec/issues/654 but with the fact **channels** could use those values for prefixing their addresses. A similar feature would be to add a [Parameter](https://www.asyncapi.com/docs/reference/specification/v2.4.0#parametersObject)...

> I would be good to extend some of the official examples, like streetlights for kafka with this feature, as this use case is most common, that Kafka has multiple...

Hi @albertnadal! I see your library can also parse AsyncAPI yaml docs (not sure about JSON format), meaning it could be used as an AsyncAPI parser for python. Is that...

> I would actually suggest we give it 3 months. It's going to be a huge change 😅 +1. EDIT: I also +1 what @dalelane says below: > For v3,...

I see and agree the source of truth of the spec can become unclear. In fact, I think it becomes less clear for contributors than for users. I can also...

> > I would then like to suggest we do it on the spec document > > I guess that's automatically implied that specification itself is the single source of...

> Just an idea: how about mentioning it in README and the website? Sure, this is what I meant by: > additionally in the README, I don't mind

Also opened an issue on the SLA4OAI repo: https://github.com/isa-group/SLA4OAI-Specification/issues/17

Any plan to retake this?

More kinda related issues: - https://github.com/asyncapi/.github/issues/123 - https://github.com/asyncapi/parser-js/issues/427