| Getting children of a supertype element [message #60396] |
Sun, 03 May 2009 21:47  |
 christopher shaun ramos
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="http://www.omg.org/XMI"
xmlns:ecore="http:///test">
<ecore:navn xmi:type="ecore:FirstName">
<ecore:child1 xmi:type="ecore:child">test</ecore:child1>
</ecore:navn>
</ecore:Test>
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
'navn'.
Not satisfied with my findings, I ended up getting the latest m2t code
from eclipse, modified and ran the
EObjectInspectorTest.getNamedChildren_emf()
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
1.17),
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
handle
// matches against substitution group head elements, which must
only return
// elements of the head type, not sub-types
if
(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;
}
Thanks,
shaun
This is my metadata:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test"
nsURI="http:///test" nsPrefix="test">
<eClassifiers xsi:type="ecore:EClass" name="Name">
<eAnnotations
source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="name" value="name"/>
<details key="kind" value="empty"/>
</eAnnotations>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="FirstName"
eSuperTypes="#//Name">
<eStructuralFeatures xsi:type="ecore:EReference" name="child1"
eType="#//child"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Test">
<eAnnotations
source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="kind" value="elementOnly"/>
<details key="name" value="Test"/>
</eAnnotations>
<eStructuralFeatures xsi:type="ecore:EReference" name="first"
lowerBound="1" eType="#//Name"
containment="true" resolveProxies="false">
<eAnnotations
source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="name" value="first"/>
<details key="kind" value="element"/>
</eAnnotations>
</eStructuralFeatures>
<eStructuralFeatures xsi:type="ecore:EReference" name="navn"
eType="#//Name" containment="true"
resolveProxies="false">
<eAnnotations
source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="name" value="navn"/>
<details key="kind" value="element"/>
</eAnnotations>
</eStructuralFeatures>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="child">
<eAnnotations
source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="name" value="child1"/>
<details key="kind" value="text"/>
</eAnnotations>
</eClassifiers>
</ecore:EPackage>
|
|
|
| Re: Getting children of a supertype element [message #60442 is a reply to message #60396] |
Tue, 05 May 2009 13:32  |
Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Shaun:
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
'attributes'.
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
elements.
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.
Paul
|
|
|
Powered by
FUDForum. Page generated in 0.03157 seconds
] 
Search
Help
Register
Login
Home
