Eclipse Community Forums: M2T (model-to-text transformation) » Resolving "non-containment" EReference's

Help

Home

Home » Modeling » M2T (model-to-text transformation) » Resolving "non-containment" EReference's

Show: Today's Messages :: Show Polls :: Message Navigator

Resolving "non-containment" EReference's [message #52341]

Fri, 24 October 2008 11:40

Morten Madsen

Messages: 2
Registered: July 2009

Junior Member

Hi, my question is based on generating text from an Ecore model using JET.
I have an ecore model instance looking like this:

<documentRoot xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:bp="uri://BricksModel/1.0.0">
<bricksDiagram diagramName="Diagram1">
<bricks name="Brick1" relatedBrick="//@bricks.1"/>
<bricks name="Brick2"/>
</bricksDiagram>
</documentRoot>

You can see, because the "relatedBrick" reference is "non-containment",
the actual tag is not nested, but instead a "//@bricks.1" value is
supplied.

Do you know how to resolve these in JET? Normally you would do like:

<c:iterate select="$brick/relatedBrick" var="relBrick">
<c:get select="$brick/@name"/> => <c:get select="$relBrick/@name"/>
</c:iterate>

But this does not do anything. Anybody has an idea?

Report message to a moderator

Re: Resolving "non-containment" EReference's [message #52397 is a reply to message #52341]

Mon, 27 October 2008 16:59

Paul Elder

Messages: 849
Registered: July 2009

Senior Member

Morten:

I'm not sure what is going on. A bit more information would be useful:

1) Can you include the ECore model used?
2) How was that ECore model generated? (e.g. created directly, modeled in
project xxx, created from an XSD)

One important point to remember about JET is that, when dealing with
EMF-based models, JET IS NOT READING the XML/XMI directly. Instead, it uses
EMF to load the XML/XMI into memory as EObjects. JET then uses EMF's
reflective capabilities to map EReference and EAttribute features to XPath
concepts such as element and attribute.

From what I can deduce from about your meta-model, the folllowing XPath
expression SHOULD produce the result 'Brick2':

/documentRoot/bricksDiagram/bricks[@name = 'Brick1']/relatedBrick/@name

However, the existence of an element named 'documentRoot' makes me
suspicious that your ECore model was developed from an XSD. (EMF creates a
class called DocumentRoot in such cases - it represents the XML Document
object.) If that is the case, then it is even more confusing to then see the
XML document serialized into XMI - this typically shouldn't be done -
JET/EMF will have difficulty loading the document again (and making sense of
its contents). The one place were I have seen this happen has been in GMF
generated editors, which seem to serial via XMI, even if the ECore package
provides an other serialization mechanism.

Can you provide a bit more information?

Paul

Report message to a moderator

Re: Resolving "non-containment" EReference's [message #52744 is a reply to message #52397]

Wed, 29 October 2008 19:50

Morten Madsen

Messages: 2
Registered: July 2009

Junior Member

Hi, and thanks a lot for your answer :-).

I can understand you are a bit confused. The <documentRoot> tag is a
coincidence. I always create a <root> tag on my ecore's. Old habit, think
it's something about when you want to serialize the model, or use it
together with GMF.

The model instance in my question is created using a GMF editor, generated
from my ecore model. It is therefore fed to the transformation as a flat
XML file. I've removed the namespaces in the input XML, and renamed it
from ".bricksmodel" to ".xml".

Else I think the transformation will not accept the model, and I will get
a "property 'version' not found" in case i don't remove the
namespaces..... have you encountered this error before?

Come to think of it, renaming the extension of the model might make it
unable to recognize the EMF model, and on top of that, I'm not sure the
I've registered the model properly.

I'll make some tests and get back to you. I'm unable to access my install
of Rational Software modeler / Eclipse at the moment.

Thanks again,
Morten.

Report message to a moderator

Re: Resolving "non-containment" EReference's [message #53069 is a reply to message #52744]

Fri, 14 November 2008 18:57

Mark Wood

Messages: 8
Registered: July 2009

Junior Member

Hi Morten,

Did you ever solve this problem with non-contained references? I am having
essentially the exact same issue. I am processing an XMI file that was
generated through GMF:

<?xml version="1.0" encoding="UTF-8"?>
<wg:WebGenModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wg="http://_packagename_">

<entities name="Player">
<features xsi:type="wg:Attribute" name="name" type="//@datatypes.0"/>
</entities>
<datatypes name="String"/>
<datatypes name="Integer"/>

</wg:WebGenModel>

Notice the type reference "//@datatypes.0" which is referencing the
datatype "String".

I just want to be able to get the name attribute from the referenced
datatype.

Did you ever find a solution allowing you to follow such references?

Thanks in advance,
Mark.

Report message to a moderator

Re: Resolving "non-containment" EReference's [message #53174 is a reply to message #53069]

Tue, 18 November 2008 20:04

Paul Elder

Messages: 849
Registered: July 2009

Senior Member

Mark:

Unless you try really hard, JET delegates the loading of your input document
to EMF - JET DOES NOT read the XMI itself. What JET gets from EMF is an EMF
Resource, which contains instances of the types you defined in the ECore
model such as WebGenModel and Attribute.

Your XPath expressions are evaluated agains these objects by using EMF's
reflective interfaces. In general EAttributes are matched by attribute
steps: @xxx (or attribute::xxx) . EReferences are matched by child steps:
yyy (or child::yyy). XPath child steps will match containment and
non-containment features. The EMF Resource itself is matched by an initial
/, and the contents of the resource my be matched by providing the root
elements type, or by using the special child step 'contents' (mirroring
Resource.getContents().

So, the following XPath expression should return you the type of 'Player':

/WebGenModel/entities[@name = 'Player']/features[@name = 'name']/type/@name

as will this one:

/contents/entities[@name = 'Player']/features[@name = 'name']/type/@name

Moral of the story: when dealing with EMF serialized XMI documents, JET uses
EMF to load them, and EMF reflective APIs to traverse them. What you see in
the serialized XMI is not what JET is working against.

Paul

Report message to a moderator

Re: Resolving "non-containment" EReference's [message #53201 is a reply to message #53174]

Tue, 18 November 2008 20:39

Paul Elder

Messages: 849
Registered: July 2009

Senior Member

A small point I missed. JET will have problems loading your model if you
don't have an org.eclipse.emf.ecore.extension_parser extension point defined
for it (EMF doesn't appear to be default. You'll get some nearly useless
message about an attribute named 'version'.

To overcome this, you do either of the following

Add an extension parser declaration to the EMF plug-in that defines your
model:

<plugin>
... other stuff
<extension point="org.eclipse.emf.ecore.extension_parser">
<parser
class="org.eclipse.emf.ecore.xmi.impl.XMIResourceFactoryImpl "
type="... your models file extension..."
</extension>
</plugin>

(You will have to include the plugin org.eclipse.emf.ecore.xmi as a
dependency, too.)

Or, you can simply modify your JET project's plugin.xml to set the
modelLoader attribute on the 'transform' element to 'org.eclipse.jet.emf'

<plugin>
<extension point="org.elcipse.jet.transform">
<transform
modelLoader="org.eclipse.jet.emf"
... other attributes... >
</transform>
</extension>
</plugin>

Paul

Report message to a moderator

Previous Topic:	[Announce] M2T XPAND 0.7.0M3 is available
Next Topic:	JET2 and access to UML model

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Apr 20 00:41:32 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter