Re: [mdt-bpmn2.dev] ItemDefinition's Import is transient ?

["Hille-Doering, Reiner" <reiner.hille-doering@xxxxxxx>]

Antoine,

I say that EObject is ok for each modeled object, e.g. for XSD Types, elements, or any other EMF-based type system model. But I also mentioned that we could replace EObject with EAnyObject, which is on Java equivalent to “java.lang.Object”, so you could pass in everything.

I simply try to avoid to kill EMF’s built-in capability to resolve references – also cross Metamodels, e.g. cross BPMN->XSD.

 

Regards,

 Reiner.

 

 

 

Von: mdt-bpmn2.dev-bounces@xxxxxxxxxxx [mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] Im Auftrag von Antoine Toulme
Gesendet: Donnerstag, 16. September 2010 20:33
An: BPMN2 Developers Mailing List
Betreff: Re: [mdt-bpmn2.dev] ItemDefinition's Import is transient ?

 

Basically you're saying EObject is mostly ok for XSD types, which is not what the spec provisions: it provisions for an element.

In our case, we pass a structure reference that is an element but not part of a XSD :)

 

A qname at the very least makes it work for us. We could have a derived EObject to set the qname, so that people can either set the qname or set the EObject.

 

Thanks,

 

Antoine

On Thu, Sep 16, 2010 at 04:57, Hille-Doering, Reiner <reiner.hille-doering@xxxxxxx> wrote:

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.

 

_______________________________________________
mdt-bpmn2.dev mailing list
mdt-bpmn2.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-bpmn2.dev