NMFCode / NMF

This repository contains the entire code for the .NET Modeling Framework
BSD 3-Clause "New" or "Revised" License
36 stars 15 forks source link

Question to NMF and EMF XML output compability #34

Closed Herbie60D closed 6 years ago

Herbie60D commented 6 years ago

Hello. I’ve not much knowledge of NMF and EMF, so maybe the information I provide is not sufficient to give me an answer.

Currently I try to use a NMF to create data based on an EMF Meta model that I get from a colleague. Therefore, I use Ecore2Code.exe to generate the code and a NMF Meta model that is used in my project. I’m able to load a XML file, that was generated from a Java program based on the EMF Model in to my application. When I save the program with modelRepository.Save to XML and compare the output to the original file I loaded it looks a little bit different and when I try to load it in Eclipse I get an error because of one of the differences.

Example Eclipse EMF based XML output:

...
<stepParameter>
  <parameter xsi:type="program:PrimitiveVariable" href="Commands.program#number"/>
  <value xsi:type="program:Value" value="19">
    <type href="DataTypes.program#Integer"/>
  </value>
</stepParameter>
...

Example NMF based C# project XML output:

...
<stepParameter parameter="Commands.program#number">
  <value xsi:type="program:Value" value="19" type="DataTypes.program#Integer" />
</stepParameter>
...

The C# application reads the output of the Java application without any error. Eclipse seems to have a problem with the missing “xsi:type="program:PrimitiveVariable" for the parameter element, which is represented by NMF as attribute. NMF seems to represent all EMF elements that have an "href" attribute and no others as XML attribute with the value of the "href". The only exception is the parameter element from above. It includes a "xsi:type" attribute in EMF based output and NMF puts it in an XML attribute anyway.

Is this something that should be compatible or do I have a wrong expectation or misunderstanding?

georghinkel commented 6 years ago

Hi,

the problem is a little bit that it is nowhere documented how EMF expects the type information. To be fair, the usage in NMF neither is, but NMF is not (yet?) an industry standard.

I have the gut feeling that changing the output manually to the following will do:


...
<stepParameter parameter="program:PrimitiveValue Commands.program#number">
  <value xsi:type="program:Value" value="19" type="DataTypes.program#Integer" />
</stepParameter>
...

I experienced this also in a previous case study. If that works for you, I can change the serialization behavior. By the way, the next version will also be available as .NET 4.5 library, at least for most of the runtime libraries (just shout, if there is a library missing that you require).

Georg

Herbie60D commented 6 years ago

Hello Georg. Thank you for the fast answer. I've tested your proposal and it works great. I can load it in EMF without any error and there is no data loss. I proved this by loading an EMF generated XML file to NMF, saving the content with NMF, updating the NMF XML file with your proposed solution, loading it back to EMF and saving the content again. Both EMF XML files had identical content and structure, except for a change of the order of two entries that does not change the meaning. Please add this to your next release. If you need someone who tests it I could do it with my current project.

Best regards, Herbie

Herbie60D commented 6 years ago

Hello Georg. I saw that the new version 2.0.116 now writes the type information as you suggested. I have tested it against EMF and it loads the output without any data loss. EMF behaves a little bit strange with its type information. Sometimes it adds it explicit sometimes it is implicit, but your solution works now.