ChannelItem.$ref field deprecation + proposal how to replace it with simpler and more flexible solution

[char0n]

Hi all,

I was wondering if specification would be open to proposal of deprecating ChannelItem.$ref field and instead introduce a more flexible solution based on following spec changes:

Introduce new fixed field called channelItems to Component Object

Field Name	Type	Description
channelItems	Map[string, Channel Item Object | Reference Object]	An object to hold reusable Channel Item Objects.

Change type of Channels Object

The type of Channels Object patterned field would change from Channel Item Object to Channel Item Object | Reference Object

Deprecating the Channel Item Object $ref field.

---

This proposal makes specification more flexible (introducing reusable Channel Item Objects) and simpler as there will be only one mechanism for referencing other objects (Reference Object) instead of two (Reference Object, Channel Item Object).

Similar course of action is already in progress in OAS: OAI/OpenAPI-Specification#2635

[fmvilas]

That's a good catch 👍 I'll put this on hold while we see how to solve #520 because most probably the Channels object will be reworked too. I'm listing this issue there so we don't forget. Thanks!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[derberg]

@char0n if you want to push this one further into the spec in 3.0, next week we start meetings related to 3.0 where all folks can sync the async work 😄

Just check this calendar https://calendar.google.com/calendar/u/0/embed?src=tbrbfq4de5bcngt8okvev4lstk@group.calendar.google.com or join https://groups.google.com/u/1/g/asyncapi-users to get invites

[char0n]

@derberg sure, I'd like to be the champion of this RFC.

As far as I understand next SIG is at 25.11.2021, at 9:00 CET right? I'll be there.

[char0n]

@derberg I have an overlapping meeting in my work today. Will there be another chance to challenge this issue for 3.0 release?

[derberg]

@char0n 3.0 meetings will be regular, and happen every 2 weeks, so no worries

[char0n]

Proposed course of action:

AsyncAPI 2.x

The aim here is to limit complexity and bring more flexibility. Resolution rules around Channel Item Object.$ref field are not so clear: #612

1. Deprecate the use of $ref fixed field in Channel Item Object
2. Introduce new fixed field called channels in Components Object with type of Map[string, Channel Item Object]

AsyncAPI 3.x.

The aim here is to have single referencing mechanism within AsyncAPI 3.x spec (reducing complexity) - Reference Object

1. Remove $ref from Channel Item Object fixed fields
2. Change Channel Object patterned field type to Reference Object | Channel Item Object
3. Components Object.channels field type will change to Map[string, Channel Item Object | Reference Object]