Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-bpmn2.dev] ItemDefinition's Import is transient ?

Hi Henning,

Hi Reiner,

I think that having structureRef as EObject is ok and should be changed..


I suppose you mean't "shouldn't be changed"?

 

Yes, exactly.


 
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?

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.

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.

I agree. We should  write a custom implementation for the getter to use the same mimic that our URIHandler uses.



Reiner.

 


Back to the top