-
Notifications
You must be signed in to change notification settings - Fork 28
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
Added Capability Construct and strict schema for component style #116
Conversation
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
i tried to make the kind generic so the capabilty schema becomes generic for all entities . i think there is still some room for making them more generic ,less overlapping . and maybe reducing the number . i guess some of the kinds right now then might go into type . |
@codeSafari10 what do you think ? |
reduced kind to :
or more generic :
|
ref to the key schema is missing here . i dont know if the openapi key schema works for a general key construct |
@Jougan-0, you're going to want to get your mind wrapped around this. // @Yashsharma1911 @humblenginr |
And quickly pair a PR updating the Model Generator to reflect these changes. |
A foreseeable possibility in the future is that Capabilities might have Selectors in the same way that Relationships have Selectors. Thank you for this discussion on this concept today, @codeSafari10. |
Signed-off-by: Lee Calcote <[email protected]>
Signed-off-by: Lee Calcote <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
"additionalProperties": false, | ||
"type": "object", | ||
|
||
"required": ["schemaVersion", "version", "displayName", "kind", "type", "state", "status"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kind, type and subtype together should uniquely identify a capability. Hence subType should be required
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MUzairS15, my guess is the thinking here is that it's not always necessary to have this level specificity in order to identify a capability. Given this, that begs the idea that subtype
is optional.
If we can put some forethought into a proposed set of classifications (a set of examples of how kind, type, subtype can be made to always be present), that exercise will lend itself to making it comfortable to require subtype.
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
Signed-off-by: codeSafari10 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
"Edge", | ||
"Sibling" | ||
] | ||
"enum": ["Hierarchical", "Edge", "Sibling"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MUzairS15, please confirm that lowercased versions of these enums are supported, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would mean intercepting the validation, so let's keep them lowercase. Clients can format it when needed to display, ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds great. I will rely upon you to ensure that our current clients are compatible with lowercase values. Please suggest a change here and let’s merge and release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Relationship policies are currently compatible with lowercase?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
Signed-off-by: codeSafari10 <[email protected]>
"Edge", | ||
"Sibling" | ||
] | ||
"enum": ["Hierarchical", "Edge", "Sibling"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"enum": ["Hierarchical", "Edge", "Sibling"] | |
"enum": ["hierarchical", "edge", "sibling"] |
Notes for Reviewers
Title: Component Capabilities Schema
Description:
This PR introduces a significant refactoring of our component capabilities schema to improve scalability, flexibility, and clarity. The changes aim to flatten the capability structure and introduce a more generic, extensible approach to defining component capabilities to achieve that we are creating a new construct called
capability
Key changes:
Replaced the hierarchical object structure with a new, flattened capability construct.
Introduced a new schema for capabilities with the following key fields:
kind
: High-level category of the capabilitytype
: More specific categorization within each kindsubType
: (Optional) Most granular level of capability definitionstate
: Specifies whether the capability applies to "declaration" or "instance" state of an entitystatus
: Indicates if the capability is "enabled" or "disabled"displayName
,description
,key
for more detailed capability informationDefined enum variants for
kind
, while type and subtype are flexible to cover a wide range of capabilities without frequent schema changes.Benefits:
Example:
Old format:
New format:
Example Component Capabilities
Next Steps:
Would you like me to modify or expand on any part of this pull request description?
Signed commits