Strange XMI 2.1 for connector pointing to feature

[Frank Horn]

Just had a look at the new EA 7.5 feature of pointing connector target ends to attributes or operations. Turns out that export to XMI 2.1 yields something pretty weird, at least to my taste.

When you have a class as target of a dependency, and the class has an operation with xmi:id=EAID_5917ED5D_34A3_4fa9_8498_5B3DAC8A6531, the fact that the dependency points to this operation turns up in XMI 2.1 as

Code: [Select]

xmi:XMI/xmi:Extension/connectors/connector/style/@value="LFEP={5917ED5D-34A3-4fa9-8498-5B3DAC8A6531}L;"

I don't like this one bit, just posted it in case someone is working with XMI and wonders where to find it (like I did). Think I'll stick to GuidRef type tagged values for linking things to attributes and operations, it's more flexible anyway, and easier to parse out of XMI.

[«Midnight»]

It looks like an XPATH expression somehow got folded into the output.

[Frank Horn]

Well, no, the xpath expression is mine. Just my notation for findings in the xmi output, which is weird as well, I suppose. Sorry about that.

What I wanted to say is this: when a connector points to an operation with xmi:id=EAID_5917ED5D_34A3_4fa9_8498_5B3DAC8A6531, this will turn up in XMI 2.1 as a "value" attribute of the style node under the xmi:XMI/xmi:Extension/connectors/connector node for this connector, and the value of the "value" attribute will be

Code: [Select]

LFEP={5917ED5D-34A3-4fa9-8498-5B3DAC8A6531}L;
So to find the operation target of the connector you have to find its extension node, read the above mentioned value, strip the "LFEP={" and the "}L;" parts, and concat "EAID_" before it to get the operation id.

[«Midnight»]

Got it Frank. This made more sense once I read your other posts from the same time frame.

Unfortunately I have no solution in mind, then or now.

[Frank Horn]

David,

I wasn't looking for a solution, just wanted to document my findings (and do a little ranting, maybe, because I was disappointing by the way they handle this). Parsing it out via xsl is but a technical nuisance, not a problem. But as I said, RefGUID type tagged values are more flexible and handled a little more gracefully in XMI 2.1, so I'll stick with them while I can.

Frank

[«Midnight»]

Yeah, I see what you mean Frank.

EA leaves us with a lot of homework after an XMI export, so this is more incremental work than anything new. I guess we just have to live with it.

Thanks for surfacing the issue though. It will save many of us some hair-pulling down the line.

David