Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question to NMF and EMF XML output compability #34

Closed
Herbie60D opened this issue Jan 25, 2018 · 3 comments
Closed

Question to NMF and EMF XML output compability #34

Herbie60D opened this issue Jan 25, 2018 · 3 comments

Comments

@Herbie60D
Copy link

Herbie60D commented Jan 25, 2018

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
Copy link
Contributor

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
Copy link
Author

Herbie60D commented Jan 26, 2018

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants