If the XML Schema is really using ID and IDREF, then the instance you show isn't valid with respect to that schema. Isn't that a problem? It's more like a key/keyref, which isn't supported by Ecore either.
If it just comes down to wanting an Ecore model that can read and write such instances I would define an attribute idref
that's just a string and define a transient reference resolvedRef
of type A and I'd modify the getters and setters so that each derives sensibly from the other. I.e., when you call getResolvedRef
, it would check if the field for that is null, and if the field for the idref
has a value, it would walk the model to resolve (look up that name in the appropriate scope) and store it in the field.
It's a bit tricky to define the mutual derivation in a sensible way for both getters and both setters, but it should be possible.