Home » Archived » M2M (model-to-model transformation) » Advice on M2M technology (QVT, ATL etc)
|
| Re: Advice on M2M technology (QVT, ATL etc) [message #87745 is a reply to message #87652] |
Thu, 07 August 2008 14:25   |
Eclipse User |
|
|
|
Originally posted by: Alexander.Igdalov.borland.com
Hi Andrew,
You are right, M2M technologies such as QVT and ATL allow to transform
models at a higher level than XSL. This is because you do not have to
work with XML nodes, attributes, etc. but you operate with metamodel
entities. Moreover, you needn't have an XML (XMI) serialization of your
model - the input EMF model for a transformation might be already
instantiated.
Whereas EMF provides a Java API to work with model entities, M2M
technologies provide metamodel-oriented languages that let a user write
shorter M2M transformations than in pure Java. Moreover, they provide a
set of useful extensions which make transformation development more
convenient. Regarding QVT, these is the tracing technology, mapping
resolution mechanism, standard library operations, iterators and
especially their shorthand notation, etc. The number of these additional
benefits is permanently increasing since the OMG specification of the
QVT standard is not fully implemented yet (e.g. QVT model update
mechanism is to be implemented, which will allow a transformation not
only to create but also to update the models). Moreover, there are
commercial QVT features in the Borland Together product. The most
valuable of these is the debugger and UI capabilites. There is a chance
that in the future some of them will be moved to the open source - QVT
editor code completion is a recent example.
Cheers,
Alex.
Andrew H wrote:
> I'm rather new to the EMF world. We are investigating the use of EMF for
> our domain models. A key part of what we need to do is to transform our
> model to / from other models. Particularly as we integrate with other
> systems.
>
> These models tend to be quite different even though they cover similar
> concepts.
>
> Historically we have done this as XML to XML transformations using
> either XSLT or Velocity.
>
> But in an EMF world it seems to me (possibly naively) that we may be
> able to do things at a higher level with ecore to ecore transformations.
>
> I noticed in the EMF space there are several options. e.g.
>
> 1/ the ecore2ecore in the core EMF
> 2/ ATL
> 3/ QVT
> 4/ others?
>
> Would appreciate any pointers in regards to the strengths of these. What
> people recommend etc.
>
> regards
>
> Andrew
>
>
>
|
|
|
| Re: Advice on M2M technology (QVT, ATL etc) [message #87814 is a reply to message #87745] |
Thu, 07 August 2008 23:39 |
 Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Thanks Alex
That's encouraging. You talk mainly about QVT. Is that an endorsement of
QVT over ATL? Are they addressing the same problem or do they have
different applications / strengths & weaknesses?
Do you know if QVTR is in the works?
regards
Andrew
Alexander Igdalov wrote:
> Hi Andrew,
> You are right, M2M technologies such as QVT and ATL allow to transform
> models at a higher level than XSL. This is because you do not have to
> work with XML nodes, attributes, etc. but you operate with metamodel
> entities. Moreover, you needn't have an XML (XMI) serialization of your
> model - the input EMF model for a transformation might be already
> instantiated.
> Whereas EMF provides a Java API to work with model entities, M2M
> technologies provide metamodel-oriented languages that let a user write
> shorter M2M transformations than in pure Java. Moreover, they provide a
> set of useful extensions which make transformation development more
> convenient. Regarding QVT, these is the tracing technology, mapping
> resolution mechanism, standard library operations, iterators and
> especially their shorthand notation, etc. The number of these additional
> benefits is permanently increasing since the OMG specification of the
> QVT standard is not fully implemented yet (e.g. QVT model update
> mechanism is to be implemented, which will allow a transformation not
> only to create but also to update the models). Moreover, there are
> commercial QVT features in the Borland Together product. The most
> valuable of these is the debugger and UI capabilites. There is a chance
> that in the future some of them will be moved to the open source - QVT
> editor code completion is a recent example.
> Cheers,
> Alex.
> Andrew H wrote:
>> I'm rather new to the EMF world. We are investigating the use of EMF for
>> our domain models. A key part of what we need to do is to transform our
>> model to / from other models. Particularly as we integrate with other
>> systems.
>>
>> These models tend to be quite different even though they cover similar
>> concepts.
>>
>> Historically we have done this as XML to XML transformations using
>> either XSLT or Velocity.
>>
>> But in an EMF world it seems to me (possibly naively) that we may be
>> able to do things at a higher level with ecore to ecore transformations.
>>
>> I noticed in the EMF space there are several options. e.g.
>>
>> 1/ the ecore2ecore in the core EMF
>> 2/ ATL
>> 3/ QVT
>> 4/ others?
>>
>> Would appreciate any pointers in regards to the strengths of these. What
>> people recommend etc.
>>
>> regards
>>
>> Andrew
>>
>>
>>
|
|
|
| Re: Advice on M2M technology (QVT, ATL etc) [message #87830 is a reply to message #87814] |
Fri, 08 August 2008 07:40 |
William Piers
Messages: 301
Registered: July 2009 |
Senior Member |
|
|
Hello,
ATL and QVT have mainly the same goal : transforming models with a high
level definition language. The difference is that ATL does not attempt
to conform to the OMG's QVT specification, but purpose a simplified
language for the writing of transformations.
ATL is an hybrid transformation language, declarative and imperative,
when QVT splits those two parts into QVTR (declarative) and QVT
Operational Mappings (imperative). ATL specification consists on a
virtual machine dedicated to model to model transformations, at a low
granularity level : That's why QVTR is compiled and executed on the ATL
virtual machine.
From an user point of view, writing an ATL transformation consists on
describing each mapping between source an target model elements in
rules, and traceability links between different rules are automatically
resolved.
Future developments on ATL mainly concerns ui improvements (wizards,
completion, syntax colors) and core features (in-place transformation,
industrial integration).
There is a lot of examples and documentations on ATL, that you can find
on the project's site, e.g.
http://www.eclipse.org/m2m/atl/basicExamples_Patterns/
And finally, ATL has been successfully used in many industrial contexts,
has you can see in the "uses cases" section :
http://www.eclipse.org/m2m/atl/usecases/
Best regards,
William
Andrew H a écrit :
> Thanks Alex
>
> That's encouraging. You talk mainly about QVT. Is that an endorsement of
> QVT over ATL? Are they addressing the same problem or do they have
> different applications / strengths & weaknesses?
>
> Do you know if QVTR is in the works?
>
> regards
>
> Andrew
>
> Alexander Igdalov wrote:
>
>> Hi Andrew,
>
>> You are right, M2M technologies such as QVT and ATL allow to transform
>> models at a higher level than XSL. This is because you do not have to
>> work with XML nodes, attributes, etc. but you operate with metamodel
>> entities. Moreover, you needn't have an XML (XMI) serialization of
>> your model - the input EMF model for a transformation might be already
>> instantiated.
>> Whereas EMF provides a Java API to work with model entities, M2M
>> technologies provide metamodel-oriented languages that let a user
>> write shorter M2M transformations than in pure Java. Moreover, they
>> provide a set of useful extensions which make transformation
>> development more convenient. Regarding QVT, these is the tracing
>> technology, mapping resolution mechanism, standard library operations,
>> iterators and especially their shorthand notation, etc. The number of
>> these additional benefits is permanently increasing since the OMG
>> specification of the QVT standard is not fully implemented yet (e.g.
>> QVT model update mechanism is to be implemented, which will allow a
>> transformation not only to create but also to update the models).
>> Moreover, there are commercial QVT features in the Borland Together
>> product. The most valuable of these is the debugger and UI
>> capabilites. There is a chance that in the future some of them will be
>> moved to the open source - QVT editor code completion is a recent
>> example.
>
>> Cheers,
>> Alex.
>
>
>> Andrew H wrote:
>>> I'm rather new to the EMF world. We are investigating the use of EMF
>>> for our domain models. A key part of what we need to do is to
>>> transform our model to / from other models. Particularly as we
>>> integrate with other systems.
>>>
>>> These models tend to be quite different even though they cover
>>> similar concepts.
>>>
>>> Historically we have done this as XML to XML transformations using
>>> either XSLT or Velocity.
>>>
>>> But in an EMF world it seems to me (possibly naively) that we may be
>>> able to do things at a higher level with ecore to ecore transformations.
>>>
>>> I noticed in the EMF space there are several options. e.g.
>>>
>>> 1/ the ecore2ecore in the core EMF
>>> 2/ ATL
>>> 3/ QVT
>>> 4/ others?
>>>
>>> Would appreciate any pointers in regards to the strengths of these.
>>> What people recommend etc.
>>>
>>> regards
>>>
>>> Andrew
>>>
>>>
>>>
>
>
|
|
|
| Re: Advice on M2M technology (QVT, ATL etc) [message #87845 is a reply to message #87830] |
Fri, 08 August 2008 08:16 |
Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Thanks William
This helps a lot. I admit I was hoping for a hybrid answer, where I can do
declarative when it works but resort to procedural when I have to.
I'm mainly concerned with horizontal m2m transformations for systems
integration where there are 2 models at the same mof level but with
different models.
My priority is for the transformations to be as simple (minimal code) as
possible. Bi-directionality would be nirvana but I'm not expecting to
achieve it. Standards are nice but lower priority than the other goals.
Would you recommend ATL over QVT in that scenario?
regards
Andrew
William Piers wrote:
> Hello,
> ATL and QVT have mainly the same goal : transforming models with a high
> level definition language. The difference is that ATL does not attempt
> to conform to the OMG's QVT specification, but purpose a simplified
> language for the writing of transformations.
> ATL is an hybrid transformation language, declarative and imperative,
> when QVT splits those two parts into QVTR (declarative) and QVT
> Operational Mappings (imperative). ATL specification consists on a
> virtual machine dedicated to model to model transformations, at a low
> granularity level : That's why QVTR is compiled and executed on the ATL
> virtual machine.
> From an user point of view, writing an ATL transformation consists on
> describing each mapping between source an target model elements in
> rules, and traceability links between different rules are automatically
> resolved.
> Future developments on ATL mainly concerns ui improvements (wizards,
> completion, syntax colors) and core features (in-place transformation,
> industrial integration).
> There is a lot of examples and documentations on ATL, that you can find
> on the project's site, e.g.
> http://www.eclipse.org/m2m/atl/basicExamples_Patterns/
> And finally, ATL has been successfully used in many industrial contexts,
> has you can see in the "uses cases" section :
> http://www.eclipse.org/m2m/atl/usecases/
> Best regards,
> William
> Andrew H a écrit :
>> Thanks Alex
>>
>> That's encouraging. You talk mainly about QVT. Is that an endorsement of
>> QVT over ATL? Are they addressing the same problem or do they have
>> different applications / strengths & weaknesses?
>>
>> Do you know if QVTR is in the works?
>>
>> regards
>>
>> Andrew
>>
>> Alexander Igdalov wrote:
>>
>>> Hi Andrew,
>>
>>> You are right, M2M technologies such as QVT and ATL allow to transform
>>> models at a higher level than XSL. This is because you do not have to
>>> work with XML nodes, attributes, etc. but you operate with metamodel
>>> entities. Moreover, you needn't have an XML (XMI) serialization of
>>> your model - the input EMF model for a transformation might be already
>>> instantiated.
>>> Whereas EMF provides a Java API to work with model entities, M2M
>>> technologies provide metamodel-oriented languages that let a user
>>> write shorter M2M transformations than in pure Java. Moreover, they
>>> provide a set of useful extensions which make transformation
>>> development more convenient. Regarding QVT, these is the tracing
>>> technology, mapping resolution mechanism, standard library operations,
>>> iterators and especially their shorthand notation, etc. The number of
>>> these additional benefits is permanently increasing since the OMG
>>> specification of the QVT standard is not fully implemented yet (e.g.
>>> QVT model update mechanism is to be implemented, which will allow a
>>> transformation not only to create but also to update the models).
>>> Moreover, there are commercial QVT features in the Borland Together
>>> product. The most valuable of these is the debugger and UI
>>> capabilites. There is a chance that in the future some of them will be
>>> moved to the open source - QVT editor code completion is a recent
>>> example.
>>
>>> Cheers,
>>> Alex.
>>
>>
>>> Andrew H wrote:
>>>> I'm rather new to the EMF world. We are investigating the use of EMF
>>>> for our domain models. A key part of what we need to do is to
>>>> transform our model to / from other models. Particularly as we
>>>> integrate with other systems.
>>>>
>>>> These models tend to be quite different even though they cover
>>>> similar concepts.
>>>>
>>>> Historically we have done this as XML to XML transformations using
>>>> either XSLT or Velocity.
>>>>
>>>> But in an EMF world it seems to me (possibly naively) that we may be
>>>> able to do things at a higher level with ecore to ecore transformations.
>>>>
>>>> I noticed in the EMF space there are several options. e.g.
>>>>
>>>> 1/ the ecore2ecore in the core EMF
>>>> 2/ ATL
>>>> 3/ QVT
>>>> 4/ others?
>>>>
>>>> Would appreciate any pointers in regards to the strengths of these.
>>>> What people recommend etc.
>>>>
>>>> regards
>>>>
>>>> Andrew
>>>>
>>>>
>>>>
>>
>>
|
|
|
| Re: Advice on M2M technology (QVT, ATL etc) [message #87872 is a reply to message #87845] |
Fri, 08 August 2008 08:58 |
William Piers
Messages: 301
Registered: July 2009 |
Senior Member |
|
|
Answers below :
Andrew H a écrit :
> Thanks William
>
> This helps a lot. I admit I was hoping for a hybrid answer, where I can
> do declarative when it works but resort to procedural when I have to.
This is the ATL "good practice" : imperative parts are available to
resolve isolated declarative lacks, but the main of ATL programmation is
declarative.
>
> I'm mainly concerned with horizontal m2m transformations for systems
> integration where there are 2 models at the same mof level but with
> different models.
At the moment ATL doesn't provide bidirectional transformation, because
the philosophy is to have two distinct transformations for each
direction, rather than only a bidirectional one which impose more
constraints on its writing.
>
> My priority is for the transformations to be as simple (minimal code) as
> possible. Bi-directionality would be nirvana but I'm not expecting to
> achieve it. Standards are nice but lower priority than the other goals.
>
> Would you recommend ATL over QVT in that scenario?
The case you mention matches with both ATL / QVT capabilities... but as
an ATL developer I recommend it, but I may be partial ;-) .
William
>
> regards
>
> Andrew
>
> William Piers wrote:
>
>> Hello,
>
>> ATL and QVT have mainly the same goal : transforming models with a
>> high level definition language. The difference is that ATL does not
>> attempt to conform to the OMG's QVT specification, but purpose a
>> simplified language for the writing of transformations.
>> ATL is an hybrid transformation language, declarative and imperative,
>> when QVT splits those two parts into QVTR (declarative) and QVT
>> Operational Mappings (imperative). ATL specification consists on a
>> virtual machine dedicated to model to model transformations, at a low
>> granularity level : That's why QVTR is compiled and executed on the
>> ATL virtual machine.
>
>> From an user point of view, writing an ATL transformation consists on
>> describing each mapping between source an target model elements in
>> rules, and traceability links between different rules are
>> automatically resolved.
>
>> Future developments on ATL mainly concerns ui improvements (wizards,
>> completion, syntax colors) and core features (in-place transformation,
>> industrial integration).
>
>> There is a lot of examples and documentations on ATL, that you can
>> find on the project's site, e.g.
>> http://www.eclipse.org/m2m/atl/basicExamples_Patterns/
>
>> And finally, ATL has been successfully used in many industrial
>> contexts, has you can see in the "uses cases" section :
>> http://www.eclipse.org/m2m/atl/usecases/
>
>> Best regards,
>
>> William
>
>> Andrew H a écrit :
>>> Thanks Alex
>>>
>>> That's encouraging. You talk mainly about QVT. Is that an endorsement
>>> of QVT over ATL? Are they addressing the same problem or do they have
>>> different applications / strengths & weaknesses?
>>>
>>> Do you know if QVTR is in the works?
>>>
>>> regards
>>>
>>> Andrew
>>>
>>> Alexander Igdalov wrote:
>>>
>>>> Hi Andrew,
>>>
>>>> You are right, M2M technologies such as QVT and ATL allow to
>>>> transform models at a higher level than XSL. This is because you do
>>>> not have to work with XML nodes, attributes, etc. but you operate
>>>> with metamodel entities. Moreover, you needn't have an XML (XMI)
>>>> serialization of your model - the input EMF model for a
>>>> transformation might be already instantiated.
>>>> Whereas EMF provides a Java API to work with model entities, M2M
>>>> technologies provide metamodel-oriented languages that let a user
>>>> write shorter M2M transformations than in pure Java. Moreover, they
>>>> provide a set of useful extensions which make transformation
>>>> development more convenient. Regarding QVT, these is the tracing
>>>> technology, mapping resolution mechanism, standard library
>>>> operations, iterators and especially their shorthand notation, etc.
>>>> The number of these additional benefits is permanently increasing
>>>> since the OMG specification of the QVT standard is not fully
>>>> implemented yet (e.g. QVT model update mechanism is to be
>>>> implemented, which will allow a transformation not only to create
>>>> but also to update the models). Moreover, there are commercial QVT
>>>> features in the Borland Together product. The most valuable of these
>>>> is the debugger and UI capabilites. There is a chance that in the
>>>> future some of them will be moved to the open source - QVT editor
>>>> code completion is a recent example.
>>>
>>>> Cheers,
>>>> Alex.
>>>
>>>
>>>> Andrew H wrote:
>>>>> I'm rather new to the EMF world. We are investigating the use of
>>>>> EMF for our domain models. A key part of what we need to do is to
>>>>> transform our model to / from other models. Particularly as we
>>>>> integrate with other systems.
>>>>>
>>>>> These models tend to be quite different even though they cover
>>>>> similar concepts.
>>>>>
>>>>> Historically we have done this as XML to XML transformations using
>>>>> either XSLT or Velocity.
>>>>>
>>>>> But in an EMF world it seems to me (possibly naively) that we may
>>>>> be able to do things at a higher level with ecore to ecore
>>>>> transformations.
>>>>>
>>>>> I noticed in the EMF space there are several options. e.g.
>>>>>
>>>>> 1/ the ecore2ecore in the core EMF
>>>>> 2/ ATL
>>>>> 3/ QVT
>>>>> 4/ others?
>>>>>
>>>>> Would appreciate any pointers in regards to the strengths of these.
>>>>> What people recommend etc.
>>>>>
>>>>> regards
>>>>>
>>>>> Andrew
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
|
|
|
| Re: Advice on M2M technology (QVT, ATL etc) [message #87916 is a reply to message #87814] |
Fri, 08 August 2008 12:35 |
| Eclipse User |
|
|
|
Originally posted by: Alexander.Igdalov.borland.com
Hi Andrew,
I completely agree with William. QVT is following the OMG spec and ATL
does not. On one hand it is a definite plus to implement a standard, on
the other - the spec is often unclear and contradicting itself, so
sometimes we implement it with exceptions leaning towards our own vision
of what is good and what is not=)) I am writing chiefly about QVT
(Operational QVT (QVTO), to be precise), because I am a QVTO developer -
and it is QVTO that I know best. Thus, I would be glad to help you if
you have any questions about QVTO.
Regarding QVTR, AFAIU, this project is active. However, it's better to
ask QVTR developers to get a more detailed picture.
Best,
Alex.
Andrew H wrote:
> Thanks Alex
>
> That's encouraging. You talk mainly about QVT. Is that an endorsement of
> QVT over ATL? Are they addressing the same problem or do they have
> different applications / strengths & weaknesses?
>
> Do you know if QVTR is in the works?
>
> regards
>
> Andrew
>
> Alexander Igdalov wrote:
>
>> Hi Andrew,
>
>> You are right, M2M technologies such as QVT and ATL allow to transform
>> models at a higher level than XSL. This is because you do not have to
>> work with XML nodes, attributes, etc. but you operate with metamodel
>> entities. Moreover, you needn't have an XML (XMI) serialization of
>> your model - the input EMF model for a transformation might be already
>> instantiated.
>> Whereas EMF provides a Java API to work with model entities, M2M
>> technologies provide metamodel-oriented languages that let a user
>> write shorter M2M transformations than in pure Java. Moreover, they
>> provide a set of useful extensions which make transformation
>> development more convenient. Regarding QVT, these is the tracing
>> technology, mapping resolution mechanism, standard library operations,
>> iterators and especially their shorthand notation, etc. The number of
>> these additional benefits is permanently increasing since the OMG
>> specification of the QVT standard is not fully implemented yet (e.g.
>> QVT model update mechanism is to be implemented, which will allow a
>> transformation not only to create but also to update the models).
>> Moreover, there are commercial QVT features in the Borland Together
>> product. The most valuable of these is the debugger and UI
>> capabilites. There is a chance that in the future some of them will be
>> moved to the open source - QVT editor code completion is a recent
>> example.
>
>> Cheers,
>> Alex.
>
>
>> Andrew H wrote:
>>> I'm rather new to the EMF world. We are investigating the use of EMF
>>> for our domain models. A key part of what we need to do is to
>>> transform our model to / from other models. Particularly as we
>>> integrate with other systems.
>>>
>>> These models tend to be quite different even though they cover
>>> similar concepts.
>>>
>>> Historically we have done this as XML to XML transformations using
>>> either XSLT or Velocity.
>>>
>>> But in an EMF world it seems to me (possibly naively) that we may be
>>> able to do things at a higher level with ecore to ecore transformations.
>>>
>>> I noticed in the EMF space there are several options. e.g.
>>>
>>> 1/ the ecore2ecore in the core EMF
>>> 2/ ATL
>>> 3/ QVT
>>> 4/ others?
>>>
>>> Would appreciate any pointers in regards to the strengths of these.
>>> What people recommend etc.
>>>
>>> regards
>>>
>>> Andrew
>>>
>>>
>>>
>
>
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 11:17:08 GMT 2024
Powered by FUDForum. Page generated in 0.04012 seconds |
] 
Search
Help
Register
Login
Home
