Add profile class and writer to cpp

[tom-hg57]

Only changes for cpp:

• Improve generated classes: add rdfid to BaseClass
• Add generation of CGMESProfile class, add profile URIs and cim namespace
• Add generation of getter functions (this will be used by CIM writer to export CIM data into several files based on CGMES profiles)

[chicco785]

@tom-hg57 I see many PRs open with several deep changes, some may even be conflicting, this makes a bit complicate for us to contribute, can you update us a bit?

fyi @HUG0-D

[tom-hg57]

@tom-hg57 I see many PRs open with several deep changes, some may even be conflicting, this makes a bit complicate for us to contribute, can you update us a bit?

Most of the changes are fixes for class or attribute types in the generated code plus generation of profile class.

Furtermore I try to minimize the interface between cimgen.py and lang_pack.py. Ideally there should be only 3 called functions:

• setup
• run_template for each class
• resolve_headers

The call to set_float_classes and set_enum_classes are now not needed anymore. I hope to get rid of the confusing calls to class_details["langPack"].base["base_class"] and class_details["langPack"].base"class_location", too.

[chicco785]

@tom-hg57 I see many PRs open with several deep changes, some may even be conflicting, this makes a bit complicate for us to contribute, can you update us a bit?

Most of the changes are fixes for class or attribute types in the generated code plus generation of profile class.

Furtermore I try to minimize the interface between cimgen.py and lang_pack.py. Ideally there should be only 3 called functions:

• setup
• run_template for each class
• resolve_headers

The call to set_float_classes and set_enum_classes are now not needed anymore. I hope to get rid of the confusing calls to class_details["langPack"].base["base_class"] and class_details["langPack"].base"class_location", too.

ok, when do you think this will be merged, so that @HUG0-D can rebase his PRs on top?
for modern python we would like to:

• model Float, String, ect, as instance of a class Primitive and similarly, derived datatypes as instances of a class CIMDatatype (cf. Primitives, enum and CIM_datatype #39)
• use them to annotate attributes data types as part of json_schema_extra annotation
• leverage the above (and @HUG0-D is working already on a prototype) to use self reflection to generated RDF out of python dataclass instances.
• next work on a reader that builds python dataclass instances by parsing rdf files.

we think reflection is a more flexible approach with dataclasses because we can easily create serialisers and parsers without needs of templates and similar things (this should work also for JSON-LD, for example).

what do you think? we are happy to have a call next week if you think the approach is interesting :)

[tom-hg57]

ok, when do you think this will be merged,

I'm not maintainer of the cimgen project.

we think reflection is a more flexible approach with dataclasses because we can easily create serialisers and parsers without needs of templates and similar things (this should work also for JSON-LD, for example).

If there is a better solution, I can remove the modernpython writer (including is_used..is_primitive_attribute in modernpython\templates\cimpy_class_template.mustache if not needed). I'm working currently more with cpp and java. I use the python stuff only for tests.

Your function is_a_cim_datatype seems useful for cpp/java, too. It could make the detection of float classes easier.

BTW: Do you think CIMDatatype is always only used as float, with fixed multiplier and unit? Like:
<cim:BaseVoltage.nominalVoltage>110.0</cim:BaseVoltage.nominalVoltage>

Or should we be prepared to parse data with value, multiplier and unit, too:
<cim:BaseVoltage.nominalVoltage.value>110.0</cim:BaseVoltage.nominalVoltage.value>
<cim:BaseVoltage.nominalVoltage.multiplier rdf:resource="http://iec.ch/TC57/2008/CIM-schema-12#UnitMultiplier.k" />
<cim:BaseVoltage.nominalVoltage.unit rdf:resource="http://iec.ch/TC57/2008/CIM-schema-12#UnitSymbol.V" />

This example is from an older CIM file. But would it be valid to use value, multiplier and unit with CGMES 2.4.15/3.0.0?

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud