[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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