[gmt-dev] Re: [gmt-dev] Re: [gmt-dev] Markus Völter comments on GMT Fram

["Markus Voelter" <schogglad@xxxxxx>]

> Yes. I would envisage that the 0.0.0 GMT Feature will contain framework,
> plus at least enough to do some minimal XML work, while by 1.0.0 we could
> have some rather better coverage. However whereas Eclipse can impose JDT
as
> prepackaged, there may be no
> GMT extras that are obligatory until QVT is stable. So we may need to
> provide a GMT+EMF feature etc as starters.

ok.

> I am relectant to support anything by default. It may become a legacy
> embarassment. So as per above there could be a standard GMT+MDR feature.

ok.

Problem is, if you just provide a f/w without a usable
implementation, nobody will use it....

> No. If we went for MOF we would upset EMF, and if we went for EMF we would
> suffer slightly from OMG incompatibility. We must be neutral, and provide
> MOF to EMF and vice-versa transformation.

ok... the usual default implementation thing applies here :-)

> Seems like we should support the B+M model representation.

yes and no. Not b+m specifically. I just think that working
on an *abstract* syntax with in-memory objects is much
more convenient than dealing with strange concrete
syntax formats.

> Again it's really about establishing future proofing. Suppose I quantify
> robustness in a RubustnessModel as requiring that 99.9% of the code is
> subject to 3 way voting on 99.9% up-time machines, and then require the
> remaining 0.1% to exhibit 99.9999% up-time. A transformation that performs
> joint analysis of  code and robustness model can ensure that the figures
are
> met. Difficult research challenge but possible, once the numbers are
there.

so this is about quality of service aspects. right?

> Yes. I got a lot of this framework going yesterday, the actual signatures
> will be slightly different in the light of experience.
> May be, but do you want all standard Java exceptions wrapped?

yes. I think an interface must only throw exceptions
that fit it's abstraction level. So, the "root cause" of
the exception can be added as the "cause" attribute
of the exception.

> A programmable transformation engine interprets/compiles/executes a
> transformation program. So if you use Saxon as a transformation engine,
the
> stylesheet is the program. Ultimately this will be an instance of the QVT
> meta-model. (There is no need for the two signatures, fixed functionality
> transformations can just ignore a null program).

ah, ok. So the program is the transformation specification (maybe
rename parameter name).

> Yes and No. Transformations can be much more efficient if a schema
> validation has already be performed,

I agree. It may be useful to specify this. ...
Can you take about metamodels instead of schemas, so that
the above sentence will be:

"Transformations can be much more efficient if the input
model has been validated with regards to its metamodel"

> and this can be regarded as just
> another transformation in which exceptions could be detected.

hmmm. maybe technically correct.
However, I think verifying a model against its metamodel
is conceptually different that a transformation.

> Yes. I alluded to this in my M4M'03 paper. It's arguably another research
> area. Any rule engine is a transformation between models, so the framework
> handles it. If it's really rule oriented, then a suitable DSL will be
> useful. I think it can be substantially driven from the
> metamodel types.


hmmm.... this is too abstract for me. Maybe in
the beginning we just support directly specified
transformations.

> I have this working nicely. The plugin defines the signatures, which can
be
> checked while creating Delegates. Only when the transformation is invoked,
> model store used, does the relevant plug-in need loading.

ok.

>
> Extract from the experimental XML support plug-in
>
>    <extension point="org.eclipse.gmt.umlx.gmt.modelActivityRegistration">
>      <transform name="Reader"
class="org.eclipse.gmt.umlx.gmt.xml.XmlToDom">
>        <input name="in" model-type="XML[x]"/>
>        <output name="out" model-type="DOM[x]"/>
>      </transform>
>      <transform name="Writer"
class="org.eclipse.gmt.umlx.gmt.xml.DomToXml">
>        <input name="in" model-type="DOM[x]"/>
>        <output name="out" model-type="XML[x]"/>
>      </transform>
>    </extension>
>
> I changed from <> to [] for nested encodings since <> is bad in XML.

:-)

> That would be nice, but any particular transformation operates on a
concrete
> representation,

no... parsing the concrete syntax to an in-memory
representation is a separate step from transforming.
The same is true for unparsing the AST to the con-
crete syntax.


> I understand that the OCL part of the Kent Modelling Framework has been
> contributed to Eclipse. I also understand that Kleppe and Warner have an
> Open Source OCL. And I think there's more. I have my own partially
debugged
> CUP parser for OCL.

ok.

Markus

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Markus Völter
mailto:voelter@xxxxxxx

voelter - ingenieurbüro für softwaretechnologie
Ziegelaecker 11, 89520 Heidenheim, Germany
Tel. +49 (0) 73 21 / 97 33 44

http://www.voelter.de
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -