-
-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistencies for schemas in server.variables and channel.parameters #583
Comments
The reason it was defined as a small subset of JSON Schema was to remove complexity in an area that would probably not need much. I agree
Because
Now I'm wondering if we really need a full JSON Schema object on parameters 😄 |
And for that we should enable the all JSON Schema keywords for string type like
At the moment you must define if it's a string, number or integer, another types are allowed but invalid in this case, but for me it covers 100% cases, so I wouldn't change it. Maybe we should go with this same approach for server variables. I understand that you afraid if someone will use the complex |
So we have options:
I prefer 3rd option, because it covers all cases, also user have possibility to define and use constraints for the number, integer types. So I suggest to change the shape of the server variable to similar object like in parameter without location: variables:
{variable_name}:
description: string
schema: ... EDIT: If we go in 2 or 3 option, it's a breaking change for |
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 ❤️ |
It should be handled in the |
@magicmatatjahu do you want to champion this? 🙂 Or can we consider this issue as needs champion? 🤔 |
@jonaslagoni I can be a champion :) |
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 ❤️ |
Still relevant. |
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 ❤️ |
As we discussed that in the asyncapi/community#587 meeting I think that we should make consistent
and
and maybe also add our wdyt? cc @fmvilas @derberg @jonaslagoni @dalelane @char0n |
TBH, I would even keep it simpler. I'd make it like the Server Variable Object right now:
And add Not even interested in |
I agree with the idea of starting with minimum, as adding more keywords is an easy contribution. Also So yeah, definitely just do in Channel Parameters what is in Server Variables |
@derberg @fmvilas So should we handle that - check that comment #880 (comment), there isn't listed that issue? |
yeah, I think so, especially that it is also related to changes in defining schemas. And yeah, it is a breaking change. We completely forgot about it when had a call, but we do not make decisions on a call anyway. So if you are willing to champion please make it clear under #880 🙏 |
🎉 This issue has been resolved in version 3.0.0-next-major-spec.11 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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 ❤️ |
I'm wondering why schema (doc/constraints) for server variables uses only a subset of JSON Schema (enum, default, examples and description) rather a full set of JSON Schema keywords like
channel.parameters.[*].schema
. I can understand that if you have server's url/host then you should have in 99% cases "hardcoded" variables for it - variable's type can be only a string and with some set of values (enum
), but maybe we should allow also more complex schema likepattern
etc? If channel's parameter has it (which is more generic), so why not server variable? I need some clarification in this place.Another question/problem: if server variable can have defined
enum
then for what theexamples
exist? I mean if there is a case, when given variable have a predefined set of values (enum
) thenexamples
===enum
, soexamples
is unnecessary. Other case, whenexamples
field is used to describe possible "other" values for variable, so maybe then we should allow more complex schema to describe the variable (see my first question)?I hope that you understand my concerns and thanks very much for comments!
The text was updated successfully, but these errors were encountered: