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?
I see two possibilities:
1.
We keep an EObject reference.
In case our mechanism can’t resolve the QName/URI, the user can access the original
QName via eObject.getProxyURI();
2.
We could make the
structureRef a EAnyObject instead of EObject. This allows also simple types,
e.g. String to be populated in. During deserialization we can try to resolve
and necessarily store the original URI as string.
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.
This is because the current XSD EMF implementation (in contrast
to WSDL) does not support ID references, which is a shame. If they would fix
(support XmlResource.getEObject(id)) it would work. But we still have the
possibility to extend the URIHandler to convert XSD IDs (QNames) to the XPath
URIs that XSD uses.
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.
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.
I agree. We should write a custom implementation for the getter
to use the same mimic that our URIHandler uses.
Reiner.