YAML as replacement of pdsc

[DavidJurajdaNXP]

Since we are already using yaml files for description of csolution, clayer and generator , I think it might be right time to replace pdsc xml by yaml .

Benefits would be:

• better readability
• elimination of coupling between classification and identification
• elimination of bundles
• user experience unification with csolution, clayer and generator (same yaml format)
• can be developed together with taxonomy

Translation from old xml format to new yaml format can be automated in order to preserve compatibility of tools with already existing data.

Are benefits listed above strong enough to justify such change?

[mdortel-stm]

Hi @DavidJurajdaNXP

Just a remark on two of your benefits:

• elimination of coupling between classification and identification
• elimination of bundles

Those are not only a format change: those items are structural changes. It is beyond moving from XML to YML, IMHO.

[DavidJurajdaNXP]

Hi @mdortel-stm, yes you are right. I mean it like: if we would decide to introduce fundamental changes, lets introduce also format (yml) change. Isolated format change is not important enough to justify the modification, but in combination with fundamental changes it might be.

[ReinhardKeil]

Unfortunately, changing the PDSC XML file format would be a costly exercise as we have (a) many packs that use the XML format, (b) tools that support XML PDSC generation, (c) established processes.

We would need to continue supporting XML formatted packs for a transition period of many years.

Also packs are containers that are consumed by developers, whereas XML file projects are written by developers. IMHO it is acceptable to use XML for packs and YML for projects.

As @mdortel-stm points out, your proposal is not just a format change from XML to YML, but also changing semantics of the content. I believe we should discuss the semantic changes independent of the format change to YML.

[tcsunhao]

According to our daily practice with XML, here we get agreement that when describing very complex data like ARM pdsc, NXP manifest, XML format is more suitable for software tools(IDE) to read instead of SW engineers(human). Take NXP DFP pdsc "conditions" element as an example,

The dependency across NXP components/drivers/middlewares with boards/devices are very complex, when mapping into pdsc(with NXP internal tools), the data is actually very difficult to read through directly from pdsc, let alone edit, practically impossible.
Recently we are trying to delivery open CMSIS toolbox in our github repo for outside customers to use , we are ok with the project csolution/cproject, but for software components which are recorded in pdsc XML file, we realize that outside customers are not able to read and edit NXP pdsc files in their daily practices(look the "conditions").

For the whole open CMSIS mechanism, the project csolution/cproject are very flexible and reusable(except the component identification at the beginning like NXP::Cclass::Cgroup::Csub, it is not easy for customers to find and enter them), customers can edit them frequently and easily. The component packs seems a little "still" at least for NXP cases, for many cases especially related to dependency, not editable.

The embedded worlds are composed of components + projects. We expect OCP can give a better/dynamical way to record and distribute SW components equal to project way and we expect to use it in daily practice(frequently updates).

The YAML is indeed user friendly for read and edit.

(Apologize in advance if I miss anything convenience in OCP)