For a given feature, the references to other features such as e.g. for data or functional dependencies are specified through index-based references such as e.g. //@features.0. However, the _features _feature of ClassModel is not ordered, so index-based access is not well-defined. This is probably a bug or at least a bad design decision in EMF to allow this and it makes the models have a weired and EMF-specific semantics. Other frameworks (in particular NMF) might take the information whether a feature is ordered more serious and then cannot perform an index access to e.g. a hash set.
This can of course be fixed by setting the features-feature of ClassModel to an ordered reference and I would recommend to change that flag.
For a given feature, the references to other features such as e.g. for data or functional dependencies are specified through index-based references such as e.g.
//@features.0
. However, the _features _feature of ClassModel is not ordered, so index-based access is not well-defined. This is probably a bug or at least a bad design decision in EMF to allow this and it makes the models have a weired and EMF-specific semantics. Other frameworks (in particular NMF) might take the information whether a feature is ordered more serious and then cannot perform an index access to e.g. a hash set.This can of course be fixed by setting the features-feature of ClassModel to an ordered reference and I would recommend to change that flag.