XMI20Serializer drags in ecore_ext

[hlindberg]

When serializing a model built with metamodel_builder, the result contains eSubTypes extension and the result is not XMI 2.0 compliant.

I could not figure out how to get rid of this since (I think) the transformer that is involved drags in ecore_ext which defines the super/sub types to be bidirectional.

To get past this problem I simply commented out the line while performing serialization.

Not sure if there is a way to load a model and serialize it to XMI without triggering the code path in question. If not, this is problem that is hard to work around.

[mthiede]

Can you give an example of the wrong XMI output?

[hlindberg]

Sure, it outputs eSubTypes everywhere.

<ecore:EPackage name="Model" xmi:version="2.0"
  xmlns:xmi="http://www.omg.org/XMI"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore">
  <eClassifiers 
    abstract="true"
    interface="false"
    instanceClassName="Puppet::Pops::Model::PopsObject"
    name="PopsObject"
    eSubTypes="#//Positioned #//Program" xsi:type="ecore:EClass"/>

The eSubTypes is there because ecore_ext brings it in (it make the super/sub-type bidirectional. (Which is a really bad idea since it alters the ecore model when the model is extended, although I understand that you may want this in a controlled environment).

[hlindberg]

(All eClassifiers looks like that)

[mthiede]

I think this is a general problem; Every serializer may be confronted with models with bidirectional references. And in all such cases it should only serialize one of the two directions. So there needs to be some way to decide. For other serializers I have a feature filter attribute which takes a proc which gets a feature and decides if it should be serialized or not. In addition, there is some standard implementation of such a filter at /rgen/serializer/opposite_reference_filter.rb.

In case of ecore model serialization, the standard filter won't do the right thing because the supertype relationship is N:M and the standard filter would order by feature name, so eSubType would be preferred over eSuperType.

I think an improved version of the XMI serializer should take such a filter proc. Then there could be a specific version for ecore models which has such a filter proc built in and decides the subtype/supertype question correctly. (In fact today, the XMI20Serializer is used as a ecore model serializer only)

[hlindberg]

In general, in a 1:m relationship, the serialization should be made on the m side. The issue here is that the relation is m:m, and thus must be serialized for both ends unless one is marked to be EStructuralFeature.transient == true since features that are transient should never be serialized.

I think the RGen serializer does not honor transient, if it did the solution would be to mark the eSuperTypes features as transient.

[mthiede]

Well m:m doesn't necessarily mean that it has to be serialized for both ends. Like in this case, serializing the supertype relation only is enough. The question is how to mark in a metamodel which one to serialize. If 'transient' is meant for that, then I think we should change the serializer to honor it. And change the ecore_ext to set it properly.