Home » Archived » M2M (model-to-model transformation) » Does transformation rules order matter?
| Does transformation rules order matter? [message #84490] |
Fri, 13 June 2008 11:58  |
Eclipse User |
|
|
|
Originally posted by: jorge.manrubia.gmail.com
Hi,
We have a transformation file wich works properly when rules present a
certain order in the ATL file (primitive transformation first, complex
transformation last).
After reading the ATL execution semantics of the manual I think that this
is not the expected result (that order shouldn't matter), so we might be
using the language in the wrong way.
So, do we pay attention to the order of transformation rules?
Thank you
Regards
|
|
|
| Re: Does transformation rules order matter? [message #84504 is a reply to message #84490] |
Fri, 13 June 2008 12:07  |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Jorge Manrubia wrote:
> We have a transformation file wich works properly when rules present a
> certain order in the ATL file (primitive transformation first, complex
> transformation last).
>
> After reading the ATL execution semantics of the manual I think that
> this is not the expected result (that order shouldn't matter), so we
> might be using the language in the wrong way.
>
> So, do we pay attention to the order of transformation rules?
The order of the transformation rules should indeed be indifferent
Every functional transformation language (XSLT/ATL/...) works this way.
Could there some dependency between them (e.g. that the complex rule
references a resulting element from the simpler rules, either direct
or through thisModule.resolveTemp()) ?
Rene
|
|
|
| [ATL] Re: Does transformation rules order matter? [message #84514 is a reply to message #84504] |
Fri, 13 June 2008 13:01 |
| Eclipse User |
|
|
|
Originally posted by: jorge.manrubia.gmail.com
Hi,
Yes, that's exactly the case. We have a complex rule making use of
elements that should be created by more simple rules. Indeed they are
created, but are not linked with the elements created by the complex rule.
If we put the complex rule first, it seems that primitive transformation
target elements don't exist when it's executed, while they are properly
created later. If we put the complex rule the last one, it works as
expected.
We are not using "resolveTemp()". I expect that normal ATL resolve
behaviour would resolve assigned elements (invoking the corresponding
SOURCE to TARGET rule first) when a SOURCE element is in the right part of
a binding.
We are very new with this engine (althought we already love it) so our
assumptions might be totally wrong.
Thank you very much for your help
Rene Ladan wrote:
> The order of the transformation rules should indeed be indifferent
> Every functional transformation language (XSLT/ATL/...) works this way.
> Could there some dependency between them (e.g. that the complex rule
> references a resulting element from the simpler rules, either direct
> or through thisModule.resolveTemp()) ?
> Rene
|
|
|
| Re: [ATL] Re: Does transformation rules order matter? [message #84524 is a reply to message #84514] |
Fri, 13 June 2008 13:29 |
 loukil
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
Jorge Manrubia a écrit :
> Hi,
>
> Yes, that's exactly the case. We have a complex rule making use of
> elements that should be created by more simple rules. Indeed they are
> created, but are not linked with the elements created by the complex
> rule. If we put the complex rule first, it seems that primitive
> transformation target elements don't exist when it's executed, while
> they are properly created later. If we put the complex rule the last
> one, it works as expected.
>
> We are not using "resolveTemp()". I expect that normal ATL resolve
> behaviour would resolve assigned elements (invoking the corresponding
> SOURCE to TARGET rule first) when a SOURCE element is in the right part
> of a binding.
>
> We are very new with this engine (althought we already love it) so our
> assumptions might be totally wrong.
>
> Thank you very much for your help
>
> Rene Ladan wrote:
>
>> The order of the transformation rules should indeed be indifferent
>> Every functional transformation language (XSLT/ATL/...) works this way.
>
>> Could there some dependency between them (e.g. that the complex rule
>> references a resulting element from the simpler rules, either direct
>> or through thisModule.resolveTemp()) ?
>
>> Rene
>
>
Hi,
As Rene said, the order of rules should be indifferent.
However, in some cases and it doesn't depend on the complexity of the
rule, you have to specify a logic order. Take a look at the example below:
rule EEnum2Enumeration extends EClassifier2Classifier {
from
ec : Ecore!EEnum
to
c : UML!Enumeration (
ownedLiteral<- ec.eLiterals
)
}
rule EDataType2DataType extends EClassifier2Classifier {
from
ec : Ecore!EDataType
to
c : UML!DataType (
)
}
As you know EEnum is a subtype of EDataType in the Ecore metametamodel,
so if you put the rule for EDataType first, you will get a strange behavior.
You need to put rules for subtypes first.
If you are not satisfy with this, you can open a bug via Eclipse Bugzilla.
Brahim.
|
|
|
| Re: [ATL] Re: Does transformation rules order matter? [message #84534 is a reply to message #84524] |
Fri, 13 June 2008 13:59 |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Brahim Loukil wrote:
> Jorge Manrubia a écrit :
>> Hi,
>>
>> Yes, that's exactly the case. We have a complex rule making use of
>> elements that should be created by more simple rules. Indeed they are
>> created, but are not linked with the elements created by the complex
>> rule. If we put the complex rule first, it seems that primitive
>> transformation target elements don't exist when it's executed, while
>> they are properly created later. If we put the complex rule the last
>> one, it works as expected.
>>
>> We are not using "resolveTemp()". I expect that normal ATL resolve
>> behaviour would resolve assigned elements (invoking the corresponding
>> SOURCE to TARGET rule first) when a SOURCE element is in the right
>> part of a binding.
>>
>> We are very new with this engine (althought we already love it) so our
>> assumptions might be totally wrong.
>>
>> Thank you very much for your help
>>
>> Rene Ladan wrote:
>>
>>> The order of the transformation rules should indeed be indifferent
>>> Every functional transformation language (XSLT/ATL/...) works this way.
>>
>>> Could there some dependency between them (e.g. that the complex rule
>>> references a resulting element from the simpler rules, either direct
>>> or through thisModule.resolveTemp()) ?
>>
>>> Rene
>>
>>
> Hi,
> As Rene said, the order of rules should be indifferent.
> However, in some cases and it doesn't depend on the complexity of the
> rule, you have to specify a logic order. Take a look at the example below:
>
> rule EEnum2Enumeration extends EClassifier2Classifier {
> from
> ec : Ecore!EEnum
> to
> c : UML!Enumeration (
> ownedLiteral<- ec.eLiterals
> )
> }
>
> rule EDataType2DataType extends EClassifier2Classifier {
> from
> ec : Ecore!EDataType
> to
> c : UML!DataType (
> )
> }
>
> As you know EEnum is a subtype of EDataType in the Ecore metametamodel,
> so if you put the rule for EDataType first, you will get a strange
> behavior.
> You need to put rules for subtypes first.
>
No, that is what oclIsTypeOf() is for.
rule EEnum2Enumeration extends EClassifier2Classifier {
from
ec : Ecore!EEnum(ec.oclIsKindOf(EEnum))
to
c : UML!Enumeration (
ownedLiteral<- ec.eLiterals
)
}
rule EDataType2DataType extends EClassifier2Classifier {
from
ec : Ecore!EDataType(ec.oclIsKindOf(EDataType))
to
c : UML!DataType (
)
}
Alternatively, the oclIsKindOf() function checks if an element is of a certain
tpye or one of its subtypes.
> If you are not satisfy with this, you can open a bug via Eclipse Bugzilla.
>
Not needed.
Rene
|
|
|
| Re: [ATL] Re: Does transformation rules order matter? [message #84542 is a reply to message #84534] |
Fri, 13 June 2008 14:19 |
loukil
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
Rene Ladan a écrit :
> Brahim Loukil wrote:
>> Jorge Manrubia a écrit :
>>> Hi,
>>>
>>> Yes, that's exactly the case. We have a complex rule making use of
>>> elements that should be created by more simple rules. Indeed they are
>>> created, but are not linked with the elements created by the complex
>>> rule. If we put the complex rule first, it seems that primitive
>>> transformation target elements don't exist when it's executed, while
>>> they are properly created later. If we put the complex rule the last
>>> one, it works as expected.
>>>
>>> We are not using "resolveTemp()". I expect that normal ATL resolve
>>> behaviour would resolve assigned elements (invoking the corresponding
>>> SOURCE to TARGET rule first) when a SOURCE element is in the right
>>> part of a binding.
>>>
>>> We are very new with this engine (althought we already love it) so
>>> our assumptions might be totally wrong.
>>>
>>> Thank you very much for your help
>>>
>>> Rene Ladan wrote:
>>>
>>>> The order of the transformation rules should indeed be indifferent
>>>> Every functional transformation language (XSLT/ATL/...) works this way.
>>>
>>>> Could there some dependency between them (e.g. that the complex rule
>>>> references a resulting element from the simpler rules, either direct
>>>> or through thisModule.resolveTemp()) ?
>>>
>>>> Rene
>>>
>>>
>> Hi,
>> As Rene said, the order of rules should be indifferent.
>> However, in some cases and it doesn't depend on the complexity of the
>> rule, you have to specify a logic order. Take a look at the example
>> below:
>>
>> rule EEnum2Enumeration extends EClassifier2Classifier {
>> from
>> ec : Ecore!EEnum to
>> c : UML!Enumeration (
>> ownedLiteral<- ec.eLiterals )
>> }
>>
>> rule EDataType2DataType extends EClassifier2Classifier {
>> from
>> ec : Ecore!EDataType to
>> c : UML!DataType (
>> )
>> }
>>
>> As you know EEnum is a subtype of EDataType in the Ecore
>> metametamodel, so if you put the rule for EDataType first, you will
>> get a strange behavior.
>> You need to put rules for subtypes first.
>>
> No, that is what oclIsTypeOf() is for.
>
> rule EEnum2Enumeration extends EClassifier2Classifier {
> from
> ec : Ecore!EEnum(ec.oclIsKindOf(EEnum))
> to
> c : UML!Enumeration (
> ownedLiteral<- ec.eLiterals
> )
> }
>
> rule EDataType2DataType extends EClassifier2Classifier {
> from
> ec : Ecore!EDataType(ec.oclIsKindOf(EDataType))
> to
> c : UML!DataType (
> )
> }
>
> Alternatively, the oclIsKindOf() function checks if an element is of a
> certain
> tpye or one of its subtypes.
>
>> If you are not satisfy with this, you can open a bug via Eclipse
>> Bugzilla.
>>
> Not needed.
>
> Rene
Yes Rene, you're right. but I'm talking about how the order could
influence the transformation execution, not how we can resolve this.
Brahim.
|
|
|
| Re: [ATL] Re: Does transformation rules order matter? [message #84554 is a reply to message #84542] |
Sat, 14 June 2008 10:27 |
| Eclipse User |
|
|
|
Originally posted by: jorge.manrubia.gmail.com
Hi,
We are already filtering by correct types in the rules.
So, what I'm going to do next week is to prepare a very simple sample, in
order to post real code here that reproduces our problem.
Thank you very much for your answers.
|
|
|
Goto Forum:
Current Time: Fri Apr 19 08:43:12 GMT 2024
Powered by FUDForum. Page generated in 0.02803 seconds |
] 
Search
Help
Register
Login
Home
