Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » Getting children of a supertype element
Getting children of a supertype element [message #60396] Sun, 03 May 2009 21:47 Go to next message
christopher shaun ramos is currently offline christopher shaun ramosFriend
Messages: 1
Registered: July 2009
Junior Member
Hi Everyone,

I hope you could help me with my little problem. My XPath expression
'navn' in my jet code does not return anything. My xml is this:

<?xml version="1.0" encoding="UTF-8"?>
<ecore:Test xmi:version="2.0" xmlns:xmi=""
<ecore:navn xmi:type="ecore:FirstName">
<ecore:child1 xmi:type="ecore:child">test</ecore:child1>

In my metadata (below), FirstName is a subtype of Name (navn)

After some debugging i found out that the matches() method in
EObjectInspector.ElementNameTester class returns false for the element
Not satisfied with my findings, I ended up getting the latest m2t code
from eclipse, modified and ran the
against my metadata and xml above and got the same result.
It seems to fail in the last check in the
EObjectInspector.ElementNameTester.matches() method which is this one:

eChild.eClass().getName().equals(containmentFeature.getEType ().getName())
--> is false

eChild.eClass().getName() returns 'FirstName' while
containmentFeature.getEType().getName() returns 'Name'

I mean i can understand why the above code returns false. In my metadata
the containmentfeature only knows that it has an etype 'Name'
and not 'FirstName' so I expect containmentFeature.getEType().getName() to
return 'Name'. What i do not understand though is the existence of the
check above? In the old version of EObjectInspector (i.e., code revision
this check does not exist. In fact when i ran the test
against the old version, my test worked and i was able to get the children
of 'navn'.

There's this comment inside the
matches() method (see code below) which maybe explains why the last check
was there. But based on the comment, it seems like the last check was only
added for substitution group elements. Does the new version fail to
consider a model just like mine?

// Note, the final condition on class names prevents subclasses of the
// declared feature type from being accepted. This is necessary to
// matches against substitution group head elements, which must
only return
// elements of the head type, not sub-types
(expandedName.getLocalPart().equals(exMD.getName(containment Feature)) &&
(expandedName.getNamespaceURI() == null
expandedName.getNamespaceURI().equals(exMD.getNamespace(cont ainmentFeature)))
(eChild instanceof AnyType ||
eChild.eClass().getName().equals(containmentFeature.getEType ().getName())))
return true;


This is my metadata:

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:ecore="" name="test"
nsURI="http:///test" nsPrefix="test">
<eClassifiers xsi:type="ecore:EClass" name="Name">
<details key="name" value="name"/>
<details key="kind" value="empty"/>
<eClassifiers xsi:type="ecore:EClass" name="FirstName"
<eStructuralFeatures xsi:type="ecore:EReference" name="child1"
<eClassifiers xsi:type="ecore:EClass" name="Test">
<details key="kind" value="elementOnly"/>
<details key="name" value="Test"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="first"
lowerBound="1" eType="#//Name"
containment="true" resolveProxies="false">
<details key="name" value="first"/>
<details key="kind" value="element"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="navn"
eType="#//Name" containment="true"
<details key="name" value="navn"/>
<details key="kind" value="element"/>
<eClassifiers xsi:type="ecore:EClass" name="child">
<details key="name" value="child1"/>
<details key="kind" value="text"/>
Re: Getting children of a supertype element [message #60442 is a reply to message #60396] Tue, 05 May 2009 13:32 Go to previous message
Paul Elder is currently offline Paul ElderFriend
Messages: 849
Registered: July 2009
Senior Member

Something is strange about your .ecore model. The bulk of the model
appears to have been generated from an XML Schema (the eAnnotations are
the give away).

But, the declaration of FirstName does not include any eAnnotations,
suggesting it was added directly to the .ecore file rather than done on
the XSD.

This is creating an environment that is confusing to the XPath engine.

Normally, on seeing an EObject, the XPath engine gets the object's
EClass and interprets EReferenes as 'elements' and EAttributes as

But, if JET finds eAnnotations on that EClass, then it does its best to
treat the EObject as a node in an XML document. All those eAnnotations
override the standard behavior. They can change the name by which an
element is identified, and they can even make EAttributes look like

My recommendation is to either define your model entirely in XSD, or
entirely in ECORE, but not both. Unless you want to serialize your model
as XML conforming to the original XSD (you are not currently doing that
- your example is serialized as XMI), I suggest removing all those
eAnnotations and letting JET using EMF's reflective APIs.

Previous Topic:[Acceleo] Text to Model
Next Topic:[Announce] M2T XPAND 0.7.0M7 is available
Goto Forum:

Current Time: Thu Mar 30 00:53:54 GMT 2017

Powered by FUDForum. Page generated in 0.02213 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software