Organizing Cclass Taxonomy

[ReinhardKeil]

Open-CMSIS-Pack should enable software re-use across software vendors and companies. To achieve this we need guidelines and this talks about the usage of Cclass/Cgroup.

Software components are defined with the element <component>.
Application Programming Interfaces (API) are defined with the element <api>.
Both use Cclass and Cgroup names to organize selectable components for software re-use.

Each Cclass and every selected Cclass/Cgroup should have one of the following modes that are validated by packchk.

• Mode: Open is used to allow extensions provided by multiple vendors. Every vendor can add additional Cgroup names. As a component has also a Cvendor, an name clash between different vendors can be resolved. Still it is recommended to avoid name clashes at the Cgroup level.
• Mode: Device is used to define device specific software components. New Cgroup names are allowed, but each component must have a dependency to a device (otherwise similar to Mode: Open).
• Mode: Board is used to define board specific software components. New Cgroup names are allowed, but each component must have a dependency to a board (otherwise similar to Mode: Open).
• Mode: Controlled is used to describe that extensions to the Cclass are possible, but controlled by the Open-CMSIS-Pack working group or by the Owner (=vendor). CMSIS, LVGL, or Memfault could be examples for such a Cclass.
• Mode: Bundle is used to publish a complete software stack with fixed functionality (i.e. File System, TCP/IP stack, etc.). Additional Cgroup names can only be added using the same Cvendor name. It is possible to have multiple bundles that use the same Cclass name.
• Mode: API is used to publish unified API header files. Implementations can be provided by various vendors using a Csub name in the element. Depending on the attribute exclusive one or more implementations may be provided. This mode is triggered by the element <apis> of a software pack.

An unexpected Cclass or Cgroup naming clash may result to incompatible operation of the Open-CMSIS-Pack system.
Sometimes even established software packs become unusable or users get confused by way components are represented.
It is therefore required to organize the Cclass/Cgroup taxonomy at the level of the Open-CMSIS-Pack project beyond the current information in the Open-CMSIS-Pack specification that is described under the element.

The implications (that should be verified by tools like packchk) of the different modes are:

• Mode: Open new Cgroup names are accepted. There might be a check for duplicates in other packs.
• Mode: Device new Cgroup names are accepted. There is a check for a device condition as the components are device specific.
• Mode: Board new Cgroup names are accepted. There is a check for a board condition as the components are boards specific.
• Mode: Controlled Cgroup are checked against Open-CMSIS-Pack-Taxonomy.XML. If not present, rejected.
• Mode: Bundle new Cgroup names are accepted. There is a check that a bundle with name is defined.
• Mode: API same as Mode:Controlled as new APIs can only be added by the Open-CMSIS-Pack working group or by the Owner (=vendor).

Proposed steps:

• Define a Open-CMSIS-Pack-Taxonomy.XML (or YML) file that lists valid Cclass definitions, along with above mode information, owner (= vendor), contact (= email), description, and optional Cgroup information.
• Specify the current Cclass usage in this Open-CMSIS-Pack-Taxonomy.XML file. Add Cgroup information where required.
• This Open-CMSIS-Pack-Taxonomy.XML file is used by packchk for validation but could be also used to display information about the registered Cclass/Cgroup.
• Use https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Taxonomy to manage the Open-CMSIS-Pack-Taxonomy.XML. Implement a contribution process similar to Simple-Icons
• Explore removal of element from software packs (*.PDSC files) as otherwise it may result in inconsistent definitions.

[ReinhardKeil]

Related to #22

[iomint]

Reinhard,
Can you explain the way you have define the list of "mode" you propose ? In particular I do not understand the rational of the "Device" mode and the consistency of a "bundle" mode vs some others e.g "open" mode is unclear to me. Furthermore, Device is already a Cclass to using it also as mode is confusing and in the same way "api" is also already an element.
For a better understanding of the mode idea, can you map the mode to the existing Cclass ? in your foreseen usage of mode is the mapping fixed or can it depends on the pack contents e.g for components with a Cclass 'graphics' can some be mapped on a mode 'bundle' and others on the mode 'controlled' or 'open' ? To my understanding the 'mode' is used to check if Cgroup can be added or not. Do you confirm ? Consequently, to my understanding of your proposal, Cclass list is fixed (limited to the existing list in Open-CMSIS-Pack spec) and enforced using Packchk. Any new Cclass addition will have to be approved by a CCB, Is it what you have in mind ?

[ReinhardKeil]

We have a better description here: https://github.com/Open-CMSIS-Pack/open-cmsis-pack-taxonomy

Also there is a start of the mapping in this file https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Taxonomy/blob/main/Open-CMSIS-Pack-Taxonomy.yaml

Any new Cclass addition will have to be approved by a CCB, Is it what you have in mind ?
Yes, I think this is what is required to ensure compatibility.

I believe we need further work on the mode "Bundle". Let's see what feedback we can get here.

[iomint]

[After Open-CMSIS-pack weekly call held 25w07, when Open-CMSIS-Pack stakeholders were asked to provide feedback]

ST is still positive on the having a CCB in relation with Open-CMSIS-Pack governance to review the new CClass/Cgroup proposals but in line with our previous comments we have still some question mark on the principle and contents of the associated "mode" proposal and the way/need to enforce it.