| [mxf-dev] [Follow up] Wish to take over MXF by Montages AG |
|
Dear Ed.
I want to follow up on the thread we interrupted on 10.01.2012 (see below). And answer the questions you asked then, to comment whether it makes sense we take over the MXF Franework. Based on your input we have evolved our work, and made all the Model Execution feature based on plain ECore feature (EOperations and EAnnotations) and made it generic with respect to used _expression_ language to define those operations, and used metamodels to define model-instances inside EAnnotations which are used as a further alternative. Details are below. Ed M.: I'll want to understand what concretely you have that fits this general scope verses what's specifically focused on OCL.Ed M.: I don't imagine what you're planning fits exactly the scope that's been spelled out.PWK Actually, we like quite the original scope of MXF. PWK: The original "general" scope proposed a concrete action language to be used to add semantics to ECore models. Our approach is to allow any action language or other kind of language to be used to add semantics. The original proposal is a good example of one language that may be useful, the current and past proposals for using Action languages in UML are other useful ways, that could be translated from the UML metamodel to the ECore metamodel. The commonality between these approaches is that they allow to define a certain order in which features of objects are updated, and operations are called. While it is trivial to model the order by derived features in a static way, the updates need to be specified. Thus our own approach is to only give means how to define which objects are updates, and for these objects, which features are set to which new vvalues. The way we do that is by defining one update by pointing to a feature, and specifying in two designated EOperations the objects to be updates, and the new values. Then there are the usual ways to define these EOperations: 1 Java 2 OCL 3 Instances of other models, calling their operations 4 QVTO 5 XBase - We will do our own experiments with OCL, and a generalization of the original proposal, which was option 3 but with a fixed metamodel. But the whole idea of EMF is that it does not matter. Thus bottomline: we do exaclty what was the original scope, but we do it in a more generic way, and add plain OCL as an option, where this is enough. Ed. M. Those places can be where the execution languages themselves are defined. I agree. People who will use our framework and support a specific execution language like OCL and XBase can then put it to those projects. Our work is about allowing to make plain ECore executable by supporting two ways: - usage of instances of one executable model to define the semantics of a second one (as in the original proposal, but in our case not restricted to one fixed metamodel) - specification of updates through EOperations, by declaring for which objects, which features change to which new values. Please let me know whether this answers your concerns about generality. All I would ask you for now is not to close that project until end of the year so we have time to discuss this further. I will meet people in the US and UK in October, and would then be prepared to discuss more in detail with you in November. Regards, Philipp On 10.01.2012 10:48, Ed Merks wrote: Philipp,
Philipp
W. Kutter
CEO, Dr. sc. ETH Montages AG Stampfenbachstr. 48 CH-8006 Zürich tel: +41 44 260 75 57 mob: +41 79 338 06 17 web: www.montages.com |