I think that having structureRef as EObject is ok and should be
changed..
I suppose you mean't "shouldn't be changed"?
I have even an example where the EObject is almost correctly resolved
from XSD schema.
It is only a matter of how good our URIHandler works: It is
responsible to use the QName, find the corresponding Import, load the file and
resolve the reference.
But structureRef could point to anything, couldn't it? Are we able to resolve that reliably or do we need some kind of fallback mechanism?
For example, in the Correlation example (I think that's what you're referring to?), trying to resolve the references to the WSDL elements fails for me with a PackageNotFoundException, because I don't have an EMF implementation for that (note: I've removed the import for DataDefinition.xsd to get rid of the namespace ambiguity you mentioned).
On the other hand, if I try to reference a XSD element, I always get back the whole schema from resolution - apparently because the XSD EMF implementation was not able to resolve by ID.
BTW: I was not able to test what would be serialized because a ran into a problem with our XmlExtendedMetadata.getNamespace implementation (endless recursion). I'll investigate this further and open a bug.
These examples highlight that we are highly dependent on the circumstances of the resolution in the case of arbitrary references. So if we want to try a resolution and not stay with QNames, we need some fallback procedure, IMO.
I don’t see why we need the “import” reference
for that resolution process – the Qname in the file is sufficient.
You're right, we don't need the import reference for resolution - but the BPMN spec prescribes the presence of this attribute (in XMI). That's why I think it's best to make it a derived attribute. The other alternative would be to remove the attribute.
Regards,
Henning
