XMI Import with correct class attribute order and type

[DN]

Hello,

we are trying to setup a toolchain for code generation.
The exchange format between the companies has been agreed to be XMI.
We would like to have Enterprise Architect as authoring tool.
The EA extensions duplicate information of the former tags and can therefore not be used.
It is importent that class attributes have alwas exactly same order (serialization) as defined in the xmi.
The type of an attribute needs to be known.


I'm facing the problem that I can not import an XMI having attribute type AND and attribute order correct.
Using ids in the EA format
    EAID_45973047_F0B1_48FB_8A64_1008228EB0E5
and the tag
    <xmi:Documentation exporter="Enterprise Architect" exporterVersion="6.5"/>
imports the types properly.
Removing the tag
    <xmi:Documentation exporter="Enterprise Architect" exporterVersion="6.5"/>
imports the class attribute order properly.

Is there any way to surcome the problem?


Thank you for any help

DN

[qwerty]

Not sure what you're doing, but sounds like XSLT could help solving your issue.

q.

[Eve]

It sounds like you're trying to generate XMI pretending it's from EA and then import it into EA.

If that's the case, EA will be looking for xmi:Extension/elements/element/attributes/containment[@position]

[DN]

Moin moin,

you are right Eve. Pretending that this file was exported from EA was my solution to surcome the problem that the xmi:idref was not resolved properly to the type of the class attribute.

Your proposal extending the xmi by adding the EA extension for order only just before importing is a good idea. I will give it a try.

In my opinion importing an xmi (not exported from EA) may still need the xmi:idref resolved properly. Maybe you can take this feature up for a future release.


Thank you

DN

[Geert Bellekens]

In my opinion importing an xmi (not exported from EA) may still need the xmi:idref resolved properly. Maybe you can take this feature up for a future release.

It does work in some cases. I did a migration from Magicdraw a while ago, and the xmi file from Magicdraw managed to keep attribute type references when imported.

Geert

[DN]

Moin Geert,

that sounds like a solution. It would be great if you could share a snippet of this file so I can see how the structure of the XMI was composed.


Thanks in advance

DN

[Geert Bellekens]

this is one of these parts.
It's been a while ago though, so I'm not sure if this was one the parts that did get recognized.

            

Code: [Select]

<ownedAttribute xmi:type='uml:Property' xmi:id='_17_0_2_eac0340_1354547256898_449719_28072' name='Type Of Metering Point' visibility='public'>
<type href='ID_4_20_15_1_26_54_PM_4539890d_14cd68d03e0__7fe2_5CB21808VL_192_168_1_95#_11_5_5300164_1164987523984_697764_707'>
<xmi:Extension extender='MagicDraw UML 18.2'>
<referenceExtension referentPath='ebix:org::Codes::ebIX Assembled::MeteringPointTypeCode::MeteringPointTypeCode' referentType='Enumeration'/>
</xmi:Extension>
</type>
<ownedComment xmi:type='uml:Comment' xmi:id='_17_0_2_eac0340_1354547256898_692502_28078' body='The type of Metering point, such as consumption, production or combined.'>
<annotatedElement xmi:idref='_17_0_2_eac0340_1354547256898_449719_28072'/>
</ownedComment>
<lowerValue xmi:type='uml:LiteralInteger' xmi:id='_17_0_2_3_38a017f_1395931856221_606173_695180'/>
<xmi:Extension extender='MagicDraw UML 18.2'>
<modelExtension>
<upperValue xmi:type='uml:LiteralUnlimitedNatural' xmi:id='_17_0_2_3_38a017f_1395931856221_972212_695181' value='1'/>
</modelExtension>
</xmi:Extension>
</ownedAttribute>
Geert

[Guillaume]

Hi DN,

As an alternative, you can import the attributes so the type is correct and fix the attributes sorting later on with a script + the expected position value that you need to import from your XMI (via an attribute tagged value or a standard field).
Attributes are sorted according to the t_attribute.pos value in the DB