RE: [m2m-dev] QVT models component

["Ed Willink" <ed@xxxxxxxxxxxxx>]

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)
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).
functionality only applicable to QVTo
	ImperativeOCL, QVTOperational models

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.]

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. 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 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.

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.

	Regards
		
		Ed willink