Jesse Menning

I would also be interested of the impact of this on #618 , especially the reference between operations and channels, which is proposed to not be a JSON ref. That...

> Of course, referencing can be a problem if we want to treat operations and channels in a registry fashion. Agree and I think registries play a large part of...

@fmvilas awesome feedback, thank you. On point 6, I see what you mean. I'm not as good at JSON as I should be. Could we do something similar to [OpenAPI...

I am intrigued by the proposal, and if we move forward with a more reference based spec these rules will become increasingly important. I will admit I'm not smart enough...

My feeling on this is that: - _Async_ encompasses a wide range of use cases, from 1:1 interactions using websockets to n:n solutions using event brokers. - If AsyncAPI aims...

As mentioned on the v3 spec call, I'd be interested in the tooling implications of this. If developers are trying to parse an AsyncAPI with a standard json parsing lib,...

@magicmatatjahu , for clarity, could you walk through how this proposal would address the [4 XSD use cases in my comment](https://github.com/asyncapi/spec/issues/624#issuecomment-932302026) in #624

I think this is great progress. I agree that a purely logical `Channel` concept, independent of the actors that use the Channel or how they use them is key to...

- 2021.07.21 - Updated to use @iancooper suggested `endpoint`, rather than `actor` ### Root of the Issues In v2.1 an AsyncAPI spec describes how other components may interact with the...

Would this be an appropriate place to have `version` to represent the semantic version? As we move into having reusable components, and presumably multiple different versions of those reusable objects,...