Home » Modeling » M2T (model-to-text transformation) » [JET] Re: Possible noob issue with xsi:type
| [JET] Re: Possible noob issue with xsi:type [message #37602] |
Thu, 06 December 2007 15:55  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Merlijn,
The problem is, that xsi:type is not really an attribute in the schema that
you're dealing with. It's just type information, and XPath 1.0 is not
aware of XSD and its type system as XPath 2.0 is.
However, it looks like you are using M2T JET, so I have replied to that
newsgroup because I think JET may provide some "extras" in its XPath
implementation that can help you.
Cheers,
Christian
Merlijn wrote:
> Dear Fellow-Eclipsers :)
>
> This is my first post and I'm probably an EMF newbie so please don't point
> and laugh when I'm asking this ;)
>
> I am trying to use JET to generate a GUI (for a school assignment, yes, it
> has been done before :)). I understand XPATH a little and thought my query
> would be good:
>
> XPATH: //eClassifier/@*[local-name()='name']
> RETURNS: 'Book'
> FROM: <eClassifiers xsi:type="ecore:EClass" name="Book">
>
> XPATH: //eClassifier/@*[local-name()='type']
> ERROR: XPath expression returned no result
> FROM: <eClassifiers xsi:type="ecore:EClass" name="Book">
>
> Which obviously isn't true... Can anyone tell me what query I would need
> to use to get the value of xsi:type?
>
> Thanks a lot in advance,
> A struggling eclipser
|
|
|
| Re: [JET] Re: Possible noob issue with xsi:type [message #37711 is a reply to message #37602] |
Mon, 10 December 2007 14:56  |
 Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Merlijn:
The invisibility of xsi:type to the XPath engine is a side effect of how JET
loads documents and traverses documents:
1) JET DOES NOT scan the input document as an XML document. Instead, it
delegates to a 'model loader', whose job it is to load the document, and
represent the XPath engine with an object representing the document (which
the XPath engine represents as '/').
2) The objects the XPath engine inteprets are not necessarily XML DOM Nodes.
Instead, the XPath engine relies on 'inspectors' that adapt an object to one
of the XPath 1.0 Data Model types (Root, Element, Attribute, Namespace,
Processing Instruction, Comment, Text).
It looks like you are reading a .ecore file, and I'm guessing you are using
the org.eclipse.jet.emf model loader. This model loader uses the registered
EMF resource implementation for .ecore files (XMIResource), and uses that to
load the document. The JET XPath engined is passed XMIResource object (which
contains an EPackage, which, in turn contains a bunch of EClass, EAttribute,
EReference, ... objects.)
All of these types EXxx types are 'inpsected' by the EObjectInspector which
does the following:
1) An EObject is generally interpreted as an Element in the XPath Data
Model. As such, it can have attributes and child elements. (In some cases it
can also have text and comment nodes, too).
2) The EObject inspector finds attributes by looking at the EObject's EClass
and looking at its EAttributes (via getAllEAttributes()). EReferences are
interpreted as child elements.
So what is happening to xsi:type? The XMIResource that parsed the .ecore
file uses xsi:type as a selector to determine what EClass (and hence the
Java class) to instantiate, but the attribute is otherwise not retained in
the loaded object.
As Christian has noted, XPath 1.0 doesn't have any built-in mechanism for
determining the type of an Element or Attribute. As a stop-gap, the
EObjectInspector does provide a hack: When attempting to find an a child
'foo', the inspector will first look for EReferences with name 'foo'. It no
such EReferences are found, then the inspector will look for contained
EObjects whose eClass name is 'foo'. Unfortunately, this is only half a
solution. It lets you test for an object of type 'foo', but it doesn't let
you write an expression that returns that object's type. So, sadly, there is
no way to write your second expression without resorting to a custom XPath
function.
The moral of today's story:
1) The XPath engine is unaware of the format on disk of a model. In some
cases, what you see on disk can be completely misleading.
2) When working with EMF-based documents, JET loads the documents via EMF
and interprets the document by looking at EMFs metadata (EClass, EAttribute,
and EReference). Your best bet in understanding how to navigate an EMF
document with XPath is to look at the EMF-generated API, and view reference
features as XPath elements and attribute features as XPath attributes.
OK, but why all the complexity of delegation to model loaders and
inspectors? Answer: extensibility. Out-of-the-box, JET can interpret any
EMF-based model, and XML document and the Eclipse workspace. I have played
with a number of other loader/inspector pairs (which should someday show up
in JET), including a loader/inspector for the JDT DOM (so you can load and
traverse a .java file) and the APT API (so you can load and traverse the
Java 5 annotations on a class).
If you are still stuck, let me know what you are trying to do. There is
probably a way around it.
Paul
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fj9620$fqb$1@build.eclipse.org...
> Hi, Merlijn,
>
> The problem is, that xsi:type is not really an attribute in the schema
> that
> you're dealing with. It's just type information, and XPath 1.0 is not
> aware of XSD and its type system as XPath 2.0 is.
>
> However, it looks like you are using M2T JET, so I have replied to that
> newsgroup because I think JET may provide some "extras" in its XPath
> implementation that can help you.
>
> Cheers,
>
> Christian
>
> Merlijn wrote:
>
>> Dear Fellow-Eclipsers :)
>>
>> This is my first post and I'm probably an EMF newbie so please don't
>> point
>> and laugh when I'm asking this ;)
>>
>> I am trying to use JET to generate a GUI (for a school assignment, yes,
>> it
>> has been done before :)). I understand XPATH a little and thought my
>> query
>> would be good:
>>
>> XPATH: //eClassifier/@*[local-name()='name']
>> RETURNS: 'Book'
>> FROM: <eClassifiers xsi:type="ecore:EClass" name="Book">
>>
>> XPATH: //eClassifier/@*[local-name()='type']
>> ERROR: XPath expression returned no result
>> FROM: <eClassifiers xsi:type="ecore:EClass" name="Book">
>>
>> Which obviously isn't true... Can anyone tell me what query I would need
>> to use to get the value of xsi:type?
>>
>> Thanks a lot in advance,
>> A struggling eclipser
>
|
|
|
Goto Forum:
Current Time: Wed Sep 18 23:37:07 GMT 2024
Powered by FUDForum. Page generated in 0.03659 seconds |
] 
Search
Help
Register
Login
Home
