Home » Modeling » M2T (model-to-text transformation) » [JET2] - XPath does not return results for UML/XMI model?
| |
| Re: [JET2] - XPath does not return results for UML/XMI model? [message #19551 is a reply to message #18388] |
Mon, 04 June 2007 13:21   |
 Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Florian:
Frances has given you the correct answer to your particular problem. Here
are some general tips to navigating a UML2 model with JET.
When JET loads a uml file (or any other file that is managed an EMF
generated meta-model), the actual EMF EObjects can loaded, and traversed by
the XPath expressions, not the XML you may see in the UML file on disk
(which in the case of UML is an XMI file).
Your best reference for navigating an UML model via JET's XPath engine is
the Javadoc for the UML2 API. When resolving an XPath 'child' step against
an UML2 (or any EObject, for that matter), JET does the following:
1) it first attempts to find a 'reference' feature with the given name. So,
//packagedElement first looks for objects containing a 'packagedElement'
feature, or, if looking in the Java doce, a method with a
getPackagedElement() method that returns a List.
2) failing the above, JET will search to for a contained object whose EClass
name is the given name, so //Package would find all instances of the EClass
Package (but not instances of its subclasses, such as Model). Note that
//packagedElement[self::Package] may give a slightly differenent result. IN
the first expression, JET will find Package instances, regardless of their
containing feature, where as the second will find them only if they are
members of a 'packagedElement' feature.
As for the disappearance of the xmi:type information, this is a direct
consequence of loading the UML model via EMF. EMF does not preserve this
information direction - it becomes the EClass name of the loaded EObject.
I'll consider whether it would be possible to construct some sort of
pseudo-attribute that would represent this information.
Paul
"Florian Georg" <florian.georg@ch.ibm.com> wrote in message
news:f3q1u3$ns1$1@build.eclipse.org...
> I'm trying to transform an UML file (XMI) into a "flat" .csv file for
> reporting.
>
> For example I'm trying to get a flat list of names of all packages.
>
> The elements I look for in the XMI file are like this:
> [...]
> <packagedElement xmi:type="uml:Package" xmi:id="_47VesBBzEdygCNyHlqJ2ww"
> name="Package1">
> [...]
>
>
> Now I define a variable in my template like this:
> <c:setVariable select="//packagedElement[@type='uml:Package']"
> var="packages"/>
>
> I know that XML namespaces are unsupported (Bugzilla #184692), but as
> mentioned in news://news.reclipse.org:119/f14ogd$t0g$1@build.eclipse.org ,
> [@type=...] should work instead of [@xmi:type=...] as long as there are no
> conflicts, right?
>
>
>
> Nevertheless, when I try to iterate over the nodes in my JET template like
> this:
>
> <c:iterate select="$packages" var="p" >
> <c:get select="$p/@name" />
> </c:iterate>
>
> this gives me no results in the output.... any ideas?
>
> Thanks in advance,
> Florian
|
|
|
| Re: [JET2] - XPath does not return results for UML/XMI model? [message #19798 is a reply to message #19551] |
Mon, 04 June 2007 20:18 |
Florian Georg
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
Dear Paul and Frances,
thanks for your clarifications, I got it working now.
Just to get it totally clear:
This means that the <c:dump > tag is of limited use, as it does not
reflect the input model as it is seen internally by JET2, right?
Is there any possibility to see more about what is going on under the
covers (e.g. when I'm unsure about the ecore schema) ?
And: Is the XPath evaluation against EMF models somehow related to EMFT
Query, or has JET2 got its own engine?
Thanks for your help,
Florian
Paul Elder schrieb:
> Florian:
>
> Frances has given you the correct answer to your particular problem. Here
> are some general tips to navigating a UML2 model with JET.
>
> When JET loads a uml file (or any other file that is managed an EMF
> generated meta-model), the actual EMF EObjects can loaded, and traversed by
> the XPath expressions, not the XML you may see in the UML file on disk
> (which in the case of UML is an XMI file).
>
> Your best reference for navigating an UML model via JET's XPath engine is
> the Javadoc for the UML2 API. When resolving an XPath 'child' step against
> an UML2 (or any EObject, for that matter), JET does the following:
>
> 1) it first attempts to find a 'reference' feature with the given name. So,
> //packagedElement first looks for objects containing a 'packagedElement'
> feature, or, if looking in the Java doce, a method with a
> getPackagedElement() method that returns a List.
>
> 2) failing the above, JET will search to for a contained object whose EClass
> name is the given name, so //Package would find all instances of the EClass
> Package (but not instances of its subclasses, such as Model). Note that
> //packagedElement[self::Package] may give a slightly differenent result. IN
> the first expression, JET will find Package instances, regardless of their
> containing feature, where as the second will find them only if they are
> members of a 'packagedElement' feature.
>
> As for the disappearance of the xmi:type information, this is a direct
> consequence of loading the UML model via EMF. EMF does not preserve this
> information direction - it becomes the EClass name of the loaded EObject.
> I'll consider whether it would be possible to construct some sort of
> pseudo-attribute that would represent this information.
>
> Paul
>
> "Florian Georg" <florian.georg@ch.ibm.com> wrote in message
> news:f3q1u3$ns1$1@build.eclipse.org...
>> I'm trying to transform an UML file (XMI) into a "flat" .csv file for
>> reporting.
>>
>> For example I'm trying to get a flat list of names of all packages.
>>
>> The elements I look for in the XMI file are like this:
>> [...]
>> <packagedElement xmi:type="uml:Package" xmi:id="_47VesBBzEdygCNyHlqJ2ww"
>> name="Package1">
>> [...]
>>
>>
>> Now I define a variable in my template like this:
>> <c:setVariable select="//packagedElement[@type='uml:Package']"
>> var="packages"/>
>>
>> I know that XML namespaces are unsupported (Bugzilla #184692), but as
>> mentioned in news://news.reclipse.org:119/f14ogd$t0g$1@build.eclipse.org ,
>> [@type=...] should work instead of [@xmi:type=...] as long as there are no
>> conflicts, right?
>>
>>
>>
>> Nevertheless, when I try to iterate over the nodes in my JET template like
>> this:
>>
>> <c:iterate select="$packages" var="p" >
>> <c:get select="$p/@name" />
>> </c:iterate>
>>
>> this gives me no results in the output.... any ideas?
>>
>> Thanks in advance,
>> Florian
>
>
|
|
|
| Re: [JET2] - XPath does not return results for UML/XMI model? [message #20100 is a reply to message #19798] |
Tue, 05 June 2007 13:05 |
Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Florian:
Yes, c:dump is mostly a debugging to, letting you see, more-or-less, what
the XPath engine sees.
In a future release, I would like to include some extensible capability of
saving models. But, to be honest, that puts JET in the model-to-model
transformation game, and I'm not sure that JET is the best tool for that.
Other debug tools are fairly limited. Some ideas:
1) c:log can be useful for dumping messages to the execution console. I
often use it to create trace information
2) The Run dialog includes an option to set the message level. Increasing
the level to 'trace' will produce information about each tag invocation.
3) There are a number of XPath functions (and tricks) you can use to explore
an object. For example, here's how to dump an attribute
<!-- dump $object's attributes -->
<c:iterate select="$object/@*" var="attr">
<c:get select="name($attr)"/> = <c:get select="$attr"/>
</c:iterate>
4) When things get truly desparate, I will often launch a runtime workbench,
and put break points in the tag handlers. The tag handlers are pretty
uniformly named. If you wan the get tag, put a break in GetTag
And, no JET's XPath engine does not use EMF Query. I'd guess it would be
possible, but the XPath engine would need to be significantly more
sophisticated to effectively use the indexes Query provides.
Paul
"Florian Georg" <florian.georg@ch.ibm.com> wrote in message
news:f41s1s$la2$1@build.eclipse.org...
> Dear Paul and Frances,
>
> thanks for your clarifications, I got it working now.
>
> Just to get it totally clear:
>
> This means that the <c:dump > tag is of limited use, as it does not
> reflect the input model as it is seen internally by JET2, right?
> Is there any possibility to see more about what is going on under the
> covers (e.g. when I'm unsure about the ecore schema) ?
>
> And: Is the XPath evaluation against EMF models somehow related to EMFT
> Query, or has JET2 got its own engine?
>
>
> Thanks for your help,
> Florian
>
>
> Paul Elder schrieb:
>> Florian:
>>
>> Frances has given you the correct answer to your particular problem. Here
>> are some general tips to navigating a UML2 model with JET.
>>
>> When JET loads a uml file (or any other file that is managed an EMF
>> generated meta-model), the actual EMF EObjects can loaded, and traversed
>> by the XPath expressions, not the XML you may see in the UML file on disk
>> (which in the case of UML is an XMI file).
>>
>> Your best reference for navigating an UML model via JET's XPath engine is
>> the Javadoc for the UML2 API. When resolving an XPath 'child' step
>> against an UML2 (or any EObject, for that matter), JET does the
>> following:
>>
>> 1) it first attempts to find a 'reference' feature with the given name.
>> So, //packagedElement first looks for objects containing a
>> 'packagedElement' feature, or, if looking in the Java doce, a method with
>> a getPackagedElement() method that returns a List.
>>
>> 2) failing the above, JET will search to for a contained object whose
>> EClass name is the given name, so //Package would find all instances of
>> the EClass Package (but not instances of its subclasses, such as Model).
>> Note that //packagedElement[self::Package] may give a slightly
>> differenent result. IN the first expression, JET will find Package
>> instances, regardless of their containing feature, where as the second
>> will find them only if they are members of a 'packagedElement' feature.
>>
>> As for the disappearance of the xmi:type information, this is a direct
>> consequence of loading the UML model via EMF. EMF does not preserve this
>> information direction - it becomes the EClass name of the loaded EObject.
>> I'll consider whether it would be possible to construct some sort of
>> pseudo-attribute that would represent this information.
>>
>> Paul
>>
>> "Florian Georg" <florian.georg@ch.ibm.com> wrote in message
>> news:f3q1u3$ns1$1@build.eclipse.org...
>>> I'm trying to transform an UML file (XMI) into a "flat" .csv file for
>>> reporting.
>>>
>>> For example I'm trying to get a flat list of names of all packages.
>>>
>>> The elements I look for in the XMI file are like this:
>>> [...]
>>> <packagedElement xmi:type="uml:Package" xmi:id="_47VesBBzEdygCNyHlqJ2ww"
>>> name="Package1">
>>> [...]
>>>
>>>
>>> Now I define a variable in my template like this:
>>> <c:setVariable select="//packagedElement[@type='uml:Package']"
>>> var="packages"/>
>>>
>>> I know that XML namespaces are unsupported (Bugzilla #184692), but as
>>> mentioned in news://news.reclipse.org:119/f14ogd$t0g$1@build.eclipse.org
>>> , [@type=...] should work instead of [@xmi:type=...] as long as there
>>> are no conflicts, right?
>>>
>>>
>>>
>>> Nevertheless, when I try to iterate over the nodes in my JET template
>>> like this:
>>>
>>> <c:iterate select="$packages" var="p" >
>>> <c:get select="$p/@name" />
>>> </c:iterate>
>>>
>>> this gives me no results in the output.... any ideas?
>>>
>>> Thanks in advance,
>>> Florian
>>
|
|
|
| Re: [JET2] - XPath does not return results for UML/XMI model? [message #20682 is a reply to message #20100] |
Tue, 05 June 2007 19:01 |
Florian Georg
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
Thanks Paul, this is very helpful.
BTW: Is there something like a JET debugger coming in the future?
I mean something to run a transformation step-by-step and seeing the
output being generated ;-)
cheers
Florian
Paul Elder schrieb:
> Florian:
>
> Yes, c:dump is mostly a debugging to, letting you see, more-or-less, what
> the XPath engine sees.
>
> In a future release, I would like to include some extensible capability of
> saving models. But, to be honest, that puts JET in the model-to-model
> transformation game, and I'm not sure that JET is the best tool for that.
>
> Other debug tools are fairly limited. Some ideas:
> 1) c:log can be useful for dumping messages to the execution console. I
> often use it to create trace information
> 2) The Run dialog includes an option to set the message level. Increasing
> the level to 'trace' will produce information about each tag invocation.
> 3) There are a number of XPath functions (and tricks) you can use to explore
> an object. For example, here's how to dump an attribute
> <!-- dump $object's attributes -->
> <c:iterate select="$object/@*" var="attr">
> <c:get select="name($attr)"/> = <c:get select="$attr"/>
> </c:iterate>
> 4) When things get truly desparate, I will often launch a runtime workbench,
> and put break points in the tag handlers. The tag handlers are pretty
> uniformly named. If you wan the get tag, put a break in GetTag
>
> And, no JET's XPath engine does not use EMF Query. I'd guess it would be
> possible, but the XPath engine would need to be significantly more
> sophisticated to effectively use the indexes Query provides.
>
> Paul
>
> "Florian Georg" <florian.georg@ch.ibm.com> wrote in message
> news:f41s1s$la2$1@build.eclipse.org...
>> Dear Paul and Frances,
>>
>> thanks for your clarifications, I got it working now.
>>
>> Just to get it totally clear:
>>
>> This means that the <c:dump > tag is of limited use, as it does not
>> reflect the input model as it is seen internally by JET2, right?
>> Is there any possibility to see more about what is going on under the
>> covers (e.g. when I'm unsure about the ecore schema) ?
>>
>> And: Is the XPath evaluation against EMF models somehow related to EMFT
>> Query, or has JET2 got its own engine?
>>
>>
>> Thanks for your help,
>> Florian
>>
>>
>> Paul Elder schrieb:
>>> Florian:
>>>
>>> Frances has given you the correct answer to your particular problem. Here
>>> are some general tips to navigating a UML2 model with JET.
>>>
>>> When JET loads a uml file (or any other file that is managed an EMF
>>> generated meta-model), the actual EMF EObjects can loaded, and traversed
>>> by the XPath expressions, not the XML you may see in the UML file on disk
>>> (which in the case of UML is an XMI file).
>>>
>>> Your best reference for navigating an UML model via JET's XPath engine is
>>> the Javadoc for the UML2 API. When resolving an XPath 'child' step
>>> against an UML2 (or any EObject, for that matter), JET does the
>>> following:
>>>
>>> 1) it first attempts to find a 'reference' feature with the given name.
>>> So, //packagedElement first looks for objects containing a
>>> 'packagedElement' feature, or, if looking in the Java doce, a method with
>>> a getPackagedElement() method that returns a List.
>>>
>>> 2) failing the above, JET will search to for a contained object whose
>>> EClass name is the given name, so //Package would find all instances of
>>> the EClass Package (but not instances of its subclasses, such as Model).
>>> Note that //packagedElement[self::Package] may give a slightly
>>> differenent result. IN the first expression, JET will find Package
>>> instances, regardless of their containing feature, where as the second
>>> will find them only if they are members of a 'packagedElement' feature.
>>>
>>> As for the disappearance of the xmi:type information, this is a direct
>>> consequence of loading the UML model via EMF. EMF does not preserve this
>>> information direction - it becomes the EClass name of the loaded EObject.
>>> I'll consider whether it would be possible to construct some sort of
>>> pseudo-attribute that would represent this information.
>>>
>>> Paul
>>>
>>> "Florian Georg" <florian.georg@ch.ibm.com> wrote in message
>>> news:f3q1u3$ns1$1@build.eclipse.org...
>>>> I'm trying to transform an UML file (XMI) into a "flat" .csv file for
>>>> reporting.
>>>>
>>>> For example I'm trying to get a flat list of names of all packages.
>>>>
>>>> The elements I look for in the XMI file are like this:
>>>> [...]
>>>> <packagedElement xmi:type="uml:Package" xmi:id="_47VesBBzEdygCNyHlqJ2ww"
>>>> name="Package1">
>>>> [...]
>>>>
>>>>
>>>> Now I define a variable in my template like this:
>>>> <c:setVariable select="//packagedElement[@type='uml:Package']"
>>>> var="packages"/>
>>>>
>>>> I know that XML namespaces are unsupported (Bugzilla #184692), but as
>>>> mentioned in news://news.reclipse.org:119/f14ogd$t0g$1@build.eclipse.org
>>>> , [@type=...] should work instead of [@xmi:type=...] as long as there
>>>> are no conflicts, right?
>>>>
>>>>
>>>>
>>>> Nevertheless, when I try to iterate over the nodes in my JET template
>>>> like this:
>>>>
>>>> <c:iterate select="$packages" var="p" >
>>>> <c:get select="$p/@name" />
>>>> </c:iterate>
>>>>
>>>> this gives me no results in the output.... any ideas?
>>>>
>>>> Thanks in advance,
>>>> Florian
>
|
|
|
| Re: [JET2] - XPath does not return results for UML/XMI model? [message #20746 is a reply to message #20682] |
Wed, 06 June 2007 12:02 |
Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Florian:
I have nothing in plan. First, I have to figure out how to clone myself :-).
But a debugger would be great, maybe someone in the community can step
forward.
Paul
"Florian Georg" <florian.georg@ch.ibm.com> wrote in message
news:f44bsg$ltv$1@build.eclipse.org...
> Thanks Paul, this is very helpful.
>
> BTW: Is there something like a JET debugger coming in the future?
> I mean something to run a transformation step-by-step and seeing the
> output being generated ;-)
>
> cheers
> Florian
>
>
> Paul Elder schrieb:
>> Florian:
>>
>> Yes, c:dump is mostly a debugging to, letting you see, more-or-less, what
>> the XPath engine sees.
>>
>> In a future release, I would like to include some extensible capability
>> of saving models. But, to be honest, that puts JET in the model-to-model
>> transformation game, and I'm not sure that JET is the best tool for that.
>>
>> Other debug tools are fairly limited. Some ideas:
>> 1) c:log can be useful for dumping messages to the execution console. I
>> often use it to create trace information
>> 2) The Run dialog includes an option to set the message level. Increasing
>> the level to 'trace' will produce information about each tag invocation.
>> 3) There are a number of XPath functions (and tricks) you can use to
>> explore an object. For example, here's how to dump an attribute
>> <!-- dump $object's attributes -->
>> <c:iterate select="$object/@*" var="attr">
>> <c:get select="name($attr)"/> = <c:get select="$attr"/>
>> </c:iterate>
>> 4) When things get truly desparate, I will often launch a runtime
>> workbench, and put break points in the tag handlers. The tag handlers are
>> pretty uniformly named. If you wan the get tag, put a break in GetTag
>>
>> And, no JET's XPath engine does not use EMF Query. I'd guess it would be
>> possible, but the XPath engine would need to be significantly more
>> sophisticated to effectively use the indexes Query provides.
>>
>> Paul
>>
>> "Florian Georg" <florian.georg@ch.ibm.com> wrote in message
>> news:f41s1s$la2$1@build.eclipse.org...
>>> Dear Paul and Frances,
>>>
>>> thanks for your clarifications, I got it working now.
>>>
>>> Just to get it totally clear:
>>>
>>> This means that the <c:dump > tag is of limited use, as it does not
>>> reflect the input model as it is seen internally by JET2, right?
>>> Is there any possibility to see more about what is going on under the
>>> covers (e.g. when I'm unsure about the ecore schema) ?
>>>
>>> And: Is the XPath evaluation against EMF models somehow related to EMFT
>>> Query, or has JET2 got its own engine?
>>>
>>>
>>> Thanks for your help,
>>> Florian
>>>
>>>
>>> Paul Elder schrieb:
>>>> Florian:
>>>>
>>>> Frances has given you the correct answer to your particular problem.
>>>> Here are some general tips to navigating a UML2 model with JET.
>>>>
>>>> When JET loads a uml file (or any other file that is managed an EMF
>>>> generated meta-model), the actual EMF EObjects can loaded, and
>>>> traversed by the XPath expressions, not the XML you may see in the UML
>>>> file on disk (which in the case of UML is an XMI file).
>>>>
>>>> Your best reference for navigating an UML model via JET's XPath engine
>>>> is the Javadoc for the UML2 API. When resolving an XPath 'child' step
>>>> against an UML2 (or any EObject, for that matter), JET does the
>>>> following:
>>>>
>>>> 1) it first attempts to find a 'reference' feature with the given name.
>>>> So, //packagedElement first looks for objects containing a
>>>> 'packagedElement' feature, or, if looking in the Java doce, a method
>>>> with a getPackagedElement() method that returns a List.
>>>>
>>>> 2) failing the above, JET will search to for a contained object whose
>>>> EClass name is the given name, so //Package would find all instances of
>>>> the EClass Package (but not instances of its subclasses, such as
>>>> Model). Note that //packagedElement[self::Package] may give a slightly
>>>> differenent result. IN the first expression, JET will find Package
>>>> instances, regardless of their containing feature, where as the second
>>>> will find them only if they are members of a 'packagedElement' feature.
>>>>
>>>> As for the disappearance of the xmi:type information, this is a direct
>>>> consequence of loading the UML model via EMF. EMF does not preserve
>>>> this information direction - it becomes the EClass name of the loaded
>>>> EObject. I'll consider whether it would be possible to construct some
>>>> sort of pseudo-attribute that would represent this information.
>>>>
>>>> Paul
>>>>
>>>> "Florian Georg" <florian.georg@ch.ibm.com> wrote in message
>>>> news:f3q1u3$ns1$1@build.eclipse.org...
>>>>> I'm trying to transform an UML file (XMI) into a "flat" .csv file for
>>>>> reporting.
>>>>>
>>>>> For example I'm trying to get a flat list of names of all packages.
>>>>>
>>>>> The elements I look for in the XMI file are like this:
>>>>> [...]
>>>>> <packagedElement xmi:type="uml:Package"
>>>>> xmi:id="_47VesBBzEdygCNyHlqJ2ww" name="Package1">
>>>>> [...]
>>>>>
>>>>>
>>>>> Now I define a variable in my template like this:
>>>>> <c:setVariable select="//packagedElement[@type='uml:Package']"
>>>>> var="packages"/>
>>>>>
>>>>> I know that XML namespaces are unsupported (Bugzilla #184692), but as
>>>>> mentioned in
>>>>> news://news.reclipse.org:119/f14ogd$t0g$1@build.eclipse.org ,
>>>>> [@type=...] should work instead of [@xmi:type=...] as long as there
>>>>> are no conflicts, right?
>>>>>
>>>>>
>>>>>
>>>>> Nevertheless, when I try to iterate over the nodes in my JET template
>>>>> like this:
>>>>>
>>>>> <c:iterate select="$packages" var="p" >
>>>>> <c:get select="$p/@name" />
>>>>> </c:iterate>
>>>>>
>>>>> this gives me no results in the output.... any ideas?
>>>>>
>>>>> Thanks in advance,
>>>>> Florian
>>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 15:54:19 GMT 2024
Powered by FUDForum. Page generated in 0.02215 seconds |
] 
Search
Help
Register
Login
Home
