[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.omelet] Re: Questions about the modelContentRegistration extension point

Hi Pepe

Yes OMELET will be able to do automatic transformation as well as conversion,
potentially after determining a huge number of intermediate steps. However
conversions are easy, they are relatively safe in terms of preservation of semantic
meaning - nobody has too much trouble with differences between an XML file
and its equivalent memory representation.

Transformations may often not be trivially semantics-preserving so it is
necessary for the meta-model to not only use a 'price' but to define
'price' as a 'over-the-counter-price', 'discount-for-cash-price',
'post-sell-by-date-price', '90-day-futures-price', 'pre-tax-price' ...
see Martin Fowler's
Analysis Patterns for further examples of how complicated a number is.

I therefore see OMELET meta-model registrations as comprising just a structural
MOF description in the short term, but an additional semantics description in the
longer term so that transformations can be validated against/adapt to the
applicable semantics. The OMELET bit is comparatively easy. The hard bit is
converting the current intuitive semantics of meta-models to machine defined
semantics. With this in place, conversion of UML 1.3 to UML 2.4 would be easy
because we would know what the UML 1.3 meant!

	Ed

Pepe Iborra wrote:
Ed

I'm sorry, my first question wasn't sufficiently explained. Yes, I was referring to the modelContentRegistration Extension Point, so your answer applies. I'm using Omelet version 0.1.0

Talking again about the model element in the mentioned extension point, in your example you propose a signature for the transformation that looks like "in1: buying, in2: pricing -> out: paying". Sorry, I'm not still completely familiar with the notation.
I understand that this signature needs the buying, pricing and paying metamodels to be previously defined using this element in the extension point right? I think I can see this clearly, it's just that since no examples are making use of this, I couldn't validate my assumption.


You say that Omelet can take care of representation formats mismatches. What about type mismatches? E.g. If someone provided the prices in another metamodel, e.g. competitor_pricing.xmi, would Omelet be able to detect this mismatch and use a registered transformation "prices: competitor_pricing -> prices2: pricing" in an automatic fashion?

Thanks for your help again
Pepe

"Ed Willink" <ed@xxxxxxxxxxxxx> escribió en el mensaje news:d0p0no$oto$1@xxxxxxxxxxxxxxxxxx

Hi Pepe


If you are working in updated docs then I'd rather wait until you finish those.

I am intending to work on updated docs just as soon as there is something worth
documenting. Don't wait.



1. What is the use of the model element?
The documentation for the extension point says " Definition of a model comprising data, or of a meta-model." so the meaning is straightforward. However I cannot find any contribution of this kind to the extension point across the set of plugins of Omelet. So what is the role of metamodels in Omelet?

I'm not quite clear what you're referring to here. Which extension point?
Which version of OMELET. Your text looks a bit like modelContentRegistration.exsd.


In OMELET a meta-model defines a type and so what a model must do to
conform to the meta-model.


I find it intriguing because I want to define a conversion/transformation that takes:
- an input ecore:param1
- an input ecore:param2
- an input mytransformationmodel:script
- an output ecore:result
And I would like to enforce the type of the script input element, i.e. I want to make sure it is an instance of my metamodel for transformations (this metamodel is defined by my tool). Would this be the right way to do it?

It's easy to get confused by meta-levels, so to take a more concrete example
of a transformation that applues pricing information to a buy-list to produce
an invoice.


We have two input meta-models: 'pricing', 'buying' and an output meta-model 'paying'.
You may enter these models with your favourite UML tool perhaps creating
e.g. pricing.xmi that you load in to Eclipse to create pricing.ecore. You might
use EMF to create an editor for pricing so that you can produce mar2005.prices.


You may use your favourite transformation technology to define a transformation
from
buy : buying, prices : pricing -> pay : paying


and invoke it with 'buy' bound to 'acme.order', 'prices' bound to 'mar2005.prices'
to produce 'acme.invoice' bound to 'pay'. Each of these files is a model
conforming to its appropriate meta-model.


When your transformation script executes, it requires its input to be presented
in a particular way - have a particular representation such as an XML File,
or a DOM tree or an XMIResource. This is where OMELET comes in, OMELET will
automatically convert to the appropriate representation (aud automatically
sequence transformations) so that transformations can be combined from a
wide variety of different sources without worrying about whether the interfaces
line up; the meta-models of the content define what is compatible.



2. What is the meaning of the symbol '%' in the model expression mini-language?
It seems to be used with the same or similar meaning as '#' for variables,

Symbols beginning % or # are type variables, so %1 is an unspecified type that must be consistently bound to a specific type when its usages are resolved in the context of the transformation/conversion invocation.

When I introduced the distinction between conversions and transformations,
I discovered that I need to distinguish between content types (e.g. UML)
and representation types e.g (XMI2 serialisation of UML).

I therefore introduced % to be explicitly a content type and could be
elaborated into a representation type.

This is something that I will tighten up/document as I reactivate the
cascaded transfdiormations.

Ed