Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2m-dev] QVT models component
Hi Ed,

Ed Willink a écrit : 
Hi Quentin

  
I developed QVTR thanks to UMLX EQVT model. This model is interesting 
for its strict conformance to the specification (even if I think some 
points of the official abstract syntax are an aberration).

However, I am surprised by your proposition of migration in the 
*infrastructure* component. Such abstract syntaxes are related to a 
language (and therefore to the corresponding M2M component):  I don't 
think I'll have any use of a QVT-OM metamodel for the 
implementation of 
QVT-R (I know the contrary might be false) and I think ATL 
has nothing 
to deal with any one of them!
    
It is certainly true that ATL has no need of QVT models.

The proposed QVT 'component' contains
functionality applicable to all QVT languages and perhaps others:
	The EMOF-Ecore mapping support
	Common models (EMOF, EssentialOCL, QvtBase)
The EMOF mapping support seems interesting but wouldn't it be relevant that you propose it to  EMF? (This is not QVT specific! Is it?)
Actually, I am seduced by the idea of Eclipse as a clean framework allowing reuse of its components, thus having every thing in its place (idem for EssentialOCL > MDT OCL).

Concerning QVTBase, for me, it is *not* relevant to all QVT languages (only to the declarative part i.e. Relations and Core)!
I think you are maybe considering the old versions of QVT (ptc/05-10-02 or even ad/2002-04-10)  but in the latest (ptc/07-07-07), any QVT OM dependency to QVTBase has disappeared!

And, as far as I know,
* for QVT Relations, we have decided to consider ptc/07-07-07:
    - as it is newer
    - the fact that ptc/07-07-07 refers to MOF2 and Ecore is adapted from MOF2 sounds good
* the QVT OM home page refers to ptc/07-07-07 as its reference...
functionality only applicable to QVTc
	QVTcore models
functionality only applicable to QVTr and QVTo
	QVTtemplate, QVTrelation models
	(NB QVTo has a single reference dependency on RelationalTransformation).
In fact, in the specification, I note at least two references from QVTOperational to QVTRelation whatever the version:
- on Relation
- on RelationDomain
ptc/07-07-07 even declares a 3rd:
- on RelationalTransformation (which make me think that, in the end, you are also considering ptc/07-07-07).

But this is not the big picture of this discussion...
functionality only applicable to QVTo
	ImperativeOCL, QVTOperational models
As a consequence of everything above, for me, nothing remains truly common to all QVT languages. And it can be easily divided in the relevant components.

I think EQVTBase, EQVTTemplate, EQVTCore and EQVTRelations hosted in the declarative QVT component is a good solution.

Maybe the QVT Operational Mappings team could give their plans about abstract syntax use..?
Packaging these into distinct plug-ins, let alone distinct components
makes things inconveniently fragmented. Currently the QVT models are in one
plug-in, EQVT models in another and common support for a third. [A fourth UI
plug-in which I overlooked in my earlier posting provides generic preference
pages for file extensions and QVT/EQVT usage.]
One plug-in for each model seems quite clean! Doesn't it?
QVTcore support is currently allocated the QVTR project, so from the point
of view of the QVT-OM project everything should be in one place,
prusumably not part of QVTR.
Why? (The QVT architecture describe a coupling, why not in a (future complete) eclipse style implementation ?) 
 The overhead of some irrelevant modules
should be a comparatively moderate bloat for QVTR compared to many
other Eclipse bloats.

The EQVTo models were first added a couple of months ago, and then
retracted while IP issues were resolved. They returned again last night.

If the QVTo bloat is a significant problem then packaging needs serious
consideration. Perhaps a QVT infrastructure component is needed.
I find this too big for such an easy thing.
M2M has already a structure in which it seems easy to incorporate your work, so what is the advantage/your interest in changing it?
Let's keep it simple!

But for such considerations, I would also be interested in the opinion of the project lead...
I would be reluctant to place the models within specific projects since
the models are more widely used:

a) Open Canarias currently use the models for their QVTcore and QVToperational support.
b) UMLX graphics re-uses the QVTr models, but does not (yet) re-use QVTR.
Why is it better to depend from one plug-in in UMLX rather than one plug-in in declarative QVT....?
The QVTr text editing and parsing within UMLX are certainly candidates for migration
to QVTR unless obsoleted by a revisit to consider use of TCS.
Indeed (and I am working on the providing integration facilities right now)!
	Regards
		
		Ed willink


_______________________________________________
m2m-dev mailing list
m2m-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2m-dev
Regards,

Quentin Glineur
begin:vcard
fn:Quentin GLINEUR
n:GLINEUR;Quentin
org:Obeo - Model Driven Company;Research and Development
adr;quoted-printable:;;2 rue Robert Schumann;Rez=C3=A9;;44400;France
email;internet:quentin.glineur@xxxxxxx
title:MDA Consultant
x-mozilla-html:TRUE
url:http://www.obeo.fr
version:2.1
end:vcard

Back to the top