Need to programmatically add XML mappings to existing class (in Shale we programmatically update xml_mappings)

[kwkwan]

When I ran bundle exec rake in the branch migrate-lutaml-model of the repo lutaml/xmi. I got the following error.

The problem may due to the methods to access xml_mappings. It may due to the changes of the mechanism to handle it.

  1) Xmi::Sparx::SparxRoot.parse_xml loading EA CityGML extension on demand after loading extension should contains original xml mapping
     Failure/Error: expect(Xmi::Sparx::SparxRoot.mappings_for(:xml).elements).to have_key(element_key)
       expected [#<Lutaml::Model::XmlMappingRule:0x0000000102e06070 @name="Extension", @to=:extension, @render_nil=fa...ild_mappings=nil, @namespace="http://www.sparxsystems.com/profiles/CityGML/1.0", @prefix="CityGML">] to respond to `has_key?`

[ronaldtse]

The PR is here:

• Migrate to lutaml-model xmi#49

[ronaldtse]

@kwkwan the internals of lutaml-model is very different from Shale.

Can you explain what exactly you want to do in this use case with some code? Thanks.

[kwkwan]

For the support of dynamic creation of the classes (e.g. CityGML), lutaml/xmi will load a XML for the definition of the classes (e.g. CityGML_MDG_Technology.xml). Then it will extend xml_mappings of EaRoot to support the new classess.

The original xml_mappings of Xmi::Sparx::SparxRoot by Shale is a hash and it has following keys:

http://www.omg.org/spec/XMI/20131001:Documentation
http://www.omg.org/spec/UML/20131001:Model
http://www.omg.org/spec/XMI/20131001:Extension
http://www.sparxsystems.com/profiles/thecustomprofile/1.0:publicationDate
...

After the dynamic creation of the classes, it is expected to have the new keys with the original keys.

http://www.omg.org/spec/XMI/20131001:Documentation
http://www.omg.org/spec/UML/20131001:Model
http://www.omg.org/spec/XMI/20131001:Extension
http://www.sparxsystems.com/profiles/thecustomprofile/1.0:publicationDate
...
http://www.sparxsystems.com/profiles/CityGML/1.0:FeatureType
http://www.sparxsystems.com/profiles/CityGML/1.0:CodeList
http://www.sparxsystems.com/profiles/CityGML/1.0:Leaf
http://www.sparxsystems.com/profiles/CityGML/1.0:ObjectType
http://www.sparxsystems.com/profiles/CityGML/1.0:BasicType
...

[ronaldtse]

@HassanAkbar this is blocking @kwkwan 's work on migrating away from Shale. Can you please help? Thanks.

[ronaldtse]

The use case is described as follows.

1. There are XML files (called "MDG files") that defines XML content structure (e.g. CityGML_MDG_Technology.xml).
2. There is a class EaRoot that inherits from Lutaml::Model::Serializable that parses an XML with a root tag <EaRoot>. This XML content has content that is "extensible" by the MDG files, i.e. if you have an MDG file, you extend the content allowed in <EaRoot>.
3. The XML file <EaRoot> needs to be parsed by the EaRoot class. This means the EaRoot class needs to be dynamically extended to:
   • parse new XML elements as defined by the MDG files
   • cast these new XML elements into different dynamically generated Lutaml::Model classes.
4. Currently, the lutaml/xmi gem dynamically hacks xml_mappings within the EaRoot class to extend it to support those dynamically-generated classes.

This is a valid use case and we should make it easy for the user to adopt. i.e., we don't want the user to hack our internal mapping (e.g. hacking xml_mappings in Shale), but provide an official mechanism to do this.

[HassanAkbar]

@ronaldtse I'm looking into it, will let you know if I have any questions.

[kwkwan]

Hi @HassanAkbar Two issues are related to this issue:

• Namespace and prefix are not inherited from default namespace and default prefix. #77
• map_element with same name but different namespace and prefix will be overwritten #78

I guess this issue may able be fixed if those two issues are fixed.

[ronaldtse]

@kwkwan these two issues have been fixed. Can you check if this issue can be closed? Thanks!

[kwkwan]

Closed #70 as completed at #77 and #78.