Added Capability Construct and strict schema for component style

[codeSafari10]

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:

1. Replaced the hierarchical object structure with a new, flattened capability construct.

2. Introduced a new schema for capabilities with the following key fields:

   • kind: High-level category of the capability
   • type: More specific categorization within each kind
   • subType: (Optional) Most granular level of capability definition
   • state: Specifies whether the capability applies to "declaration" or "instance" state of an entity
   • status: Indicates if the capability is "enabled" or "disabled"
   • Additional fields: displayName, description, key for more detailed capability information

3. Defined enum variants for kind , while type and subtype are flexible to cover a wide range of capabilities without frequent schema changes.

Benefits:

• Increased scalability: New capabilities can be added without changing the core schema.
• Improved clarity: Capabilities are now more precisely categorized and described.
• Enhanced flexibility: The new structure allows for more detailed capability definitions.
• Better organization: Capabilities are now consistently structured across different component states.

Example:

Old format:

"designer": {
  "capabilities": {
    "config": { "type": "boolean" },
    "label": { "type": "boolean" }
  }
}

New format:

{
  "kind": "configuration",
  "type": "edit",
  "subType": "component-config",
  "state": ["declaration"],
  "status": "enabled",
  "displayName": "Edit Configuration",
  "description": "Allows configuration of the component",
}

Example Component Capabilities

{
  kind : "mutate"
  type :  "configuration"
  subType : "config" | "labels" | "annotations" 
  description : "Gives the ability to edit a components configuration" 
}   // drives the configuration tooltip in extensions

{
  kind: "mutate"
  type: "style" 
  subtype : "shape" | "label"  ...  ( absence of a property means it is allowed ) 
} 

{
  kind : "interaction" 
  type: "graph"
  subtype: "allowsCompoundDragAndDrop" | "bubbleEvents" | "lock"  | "mouse-events"
} 

{
  kind: "view" 
  type: "configuration"
  subtype :  "config" | "labels" | "annotations"   // whether a readonly view is supported 
} 

{
  kind: "view" 
  type: "graph"
  subtype :  "labels" | "children" 
} 

Next Steps:

• Update all existing component definitions to use the new capability schema.
• Refactor related code to work with the new capability structure.

---

Would you like me to modify or expand on any part of this pull request description?

Signed commits

• Yes, I signed my commits.

[aabidsofi19]

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 .

[aabidsofi19]

@codeSafari10 what do you think ?

[codeSafari10]

reduced kind to :

    "kind": {
      "$ref": "../core.json#/definitions/inputString",
      "description": "Kind of the capability",
      "anyOf": [
        {
          "const": "configuration",
          "description": "For capabilities related to entities configuration  like config, labels , annotations,etc"
        },
        {
          "const": "visualization",
          "description": "For capabilities related to visualization of entities like labels , styles"
        },
        {
          "const": "lifecycle",
          "description": "For capabilities related to lifecycle mamangement of entities like deploy, undeploy ,start, stop, restart, etc"
        },

        {
          "const": "action",
          "description": "Catch all for capabilities related to actions on entities like delete,run, execute, etc"
        }
      ]
    },

or more generic :

  {
          "const": "action",
          "description": "For capabilities related to executing actions on entities"
        },
        {
          "const": "mutate",
          "description": "For capabilities related to mutating an entity"
        },

        {
          "const": "interaction",
          "description": "Catch all for capabilities related to interaction with entities"
        }
      ]

[codeSafari10]

ref to the key schema is missing here . i dont know if the openapi key schema works for a general key construct

[leecalcote]

@Jougan-0, you're going to want to get your mind wrapped around this. // @Yashsharma1911 @humblenginr

[leecalcote]

@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.

[leecalcote]

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.

[MUzairS15]

kind, type and subtype together should uniquely identify a capability. Hence subType should be required

[leecalcote]

@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.

[leecalcote]

LGTM

[leecalcote]

@MUzairS15, please confirm that lowercased versions of these enums are supported, too.

[MUzairS15]

That would mean intercepting the validation, so let's keep them lowercase. Clients can format it when needed to display, ok?

[leecalcote]

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.

[leecalcote]

Relationship policies are currently compatible with lowercase?

[MUzairS15]

yes

[MUzairS15]

Suggested change

	"enum": ["Hierarchical", "Edge", "Sibling"]
	"enum": ["hierarchical", "edge", "sibling"]