The key advantages are model and code are in a single place and are therefore maintained simultaneously (avoiding RTE problems keeping code and model synchronised), a single familiar syntax, and works with existing coding tools.

Of course, for large/complex models this is likely to start to break down.

An existing (although somewhat trivial) example of this can be seen in the @model etc javadoc annotations used by EMF.

[update: It seems that the problem is not with the serialisation, but that the Resource "contains" the objects twice. How does this happen? First the objects are added to the Resource with getContents().add(objectx), then later something like object1.setParent(object2) is called where parent is a containment relationship. Thus, the resource "directly" contains object1 and object2 but also transitively contains object1 via the containment from object2.

The real question is "why?". In earlier versions of Tefkat this did not happen. When the transitive containment was established the direct containment was removed (I think -- it could be that the serialisation was smart and ignored the duplicates). Either way, this is something that's crept into EMF in one of the more recent releases (2.2.0 or 2.2.1 maybe?). So far, no joy on tracking down the real root of the regression.]

To cut a long story short, the problem we were running in to is that there are different function symbols in the implicit FROM clauses of each of the rules, thus leading to the situation where separate Bar and Baz instances were being created and then asserted as being the same object.

My first instinct was to say, “oh, we’ve found an implementation bug, let’s fix it“. I was thinking that while the Tefkat FROM clauses must behave as injections, that there were actually effectively multiple functions involved and thus it was okay for one(f) = two(f). Unfortunately, it’s not that simple; in summary, my original Tefkat implementation was correctly implementing an injective function of the form I(<func>, <args>) and thus ensuring I(one, f) != I(two, f).

In summary, the fragment MAKE Foo f FROM p(1), Foo f FROM q(1) will always fail (consider the semantically equivalent fragment MAKE Foo f FROM p(1), Foo g FROM q(1) SET f = g).

So, what’s the F-Logic reference in the title about? Well, F-Logic allows the definition of one’s own equality theory, Tefkat is based on a (very) restricted subset of F-Logic, and the FROM “functions” in Tefkat behave as F-Logic OIDs. That is, they act as logical object identifiers, and an F-Logic equality theory allows you to say that two (or more) logical object identifiers refer to the same object.

What does all this mean? Well, it means that there is a formal basis we can use to allow for multiple injective functions, but there is a cost. The cost is that any test for object equality (or inequality) must take into account any specific equality theory defined by the transformation rules. Fortunately, such an equality theory can only apply to objects created by the transformation which limits the impact somewhat, but even so I’m not yet sure that the cost of the resulting inter-rule dependencies is not too high. It’s not even clear, from a language usability-design perspective, if there is much of a gain in allowing MAKE Foo f FROM p(1), Foo f FROM q(1).

I think the path to understanding and answering this last question may be had from an analysis of the underlying relationship between Tefkat’s transformation rules and the mathematics of mapping relations between models along the lines of Akehurst, Kent, and Patrascoiu’s “A relational approach to defining and implementing transformations between metamodels“ (actually, I’m yet to read this paper, but I think it should be relevant based on David Akehurt’s other publications on the topic).

damn

For the record, the changes were as follows:

• Added support for arbitrary XML documents as model instances, as well as using XSD (XML Schema) documents as (meta)models
• TrackingUse (LINKS/LINKING) now refers to the tracking class by name rather than by a reference to the EClass (this allows dynamically generated ECore models such as occurs when using XML Schema

Today I browsed over to this article by Dave Thomas (of smalltalk fame), a sometime DSTC visitor, and found this sentence:

Closely related to this is the interesting work on making relationships found in ER and UML models first class types in a programming language [2].

[2] Gavin Bierman, Alisdair Wren, First-Class relationships in an object-oriented language, ECOOP 2005, http://www.cl.cam.ac.uk/~aw345/talks/ecoop05.pdf

The link goes to the slides, and I haven’t spent time on the details, but I’m glad other people are thinking about this too.

svn co https://svn.sourceforge.net/svnroot/tefkat/trunk tefkat

Note that I expect there will be a complete package rename (to replace the vestigal com.dstc) before the first release.

• Not accessible via ant, can not be composed into larger transformation chains.
  An Ant Task is in the works, but Tefkat can be called from the command line so it is invokable from Ant and Make. To be fair, this is not documented and the current distribution is in the form of an Eclipse plugin rather than a standalone application so it’s not readily apparent.
• Can not reuse transformation fragments (e.g., no include/import capability)
  This is a known problem and one I hope to address as soon as I have the time.
• Requires fixed,static set of sources and targets, which are identified in a configuration model.  In practice, provisioning requires an arbitrary and dynamically determined set of sources and targets.
  Not quite. You can use a configuration model instance and this was the only way to invoke Tefkat in the early releases, but you can also specify source/target models and other parameters via an Eclipse launch configuration. See next item…
• Requires explicit tagging of each project with a tefkat nature, plus manual creation and maintenance of a configuration model.
  This is one way to do it, but not the only way. You can invoke transformations from the Run… and Debug… menu items and specify the sources and targets there. This means that you can select from any of a number of (named) different configuration options as with any Eclipse launch item. It also means you can drop into the source-level debugger and step through your transformation rules.
• No possibility for incremental target model updates.
  I’m not sure how to interpret this comment. I suspect it means that you always construct an entirely new target model instance on each run, rather than “just” updating an existing one. This is a fair comment and we are working on two alternative approaches to addressing it:
  1. a merge-based approach, which will also preserve any manual changes made to the target model instance, and
  2. an update-mode that will operate directly on an existing target model.
• No possibility for determining scope of incremental source model updates.
  Again, I’m not sure how to interpret this comment.
• No default transformations.  For example, a copy of an instance of a source model to an instance of a target model requires a fully elaborated transformation, element by element, containment by containment, association by association, attribute by attribute.
  It is quite simple to write such a transformation reflectively (requires approx. three rules), but this is an area that we need to address beyond supporting include/import of other transformations.
• Parameterization of transform would only be possible via an additional source model.  Environmental state/properties are not accessible.
  This is intended to change. Restricting the inputs of a transformation to be source model instances was a mistake. A future Tefkat version will allow arbitrary objects/values as input.
• Use of internal EMF api reduces portability across EMF versions.   Different versions of EMF alter behavior of QVT engine.
  I’d like to know which specific API this is in reference to. This may be due to the mechanism currently used to support narrowing a target object’s type, but if you do not need this functionality then there shouldn’t be a problem.
• Extremely poor performance.   Use of multiple elements in a “FOR ALL” may result in exponential number of WHERE evaluations across entire model.
  This was a problem for older versions of Tefkat, but it now has term-selection rules that attempt to mitigate this problem and avoid computing cross-products where navigation in WHERE clauses can be used instead.
• No recursively defined templates.
  These should be supported, but I don’t recall ever checking that recursive templates work. Certainly this is the first time I’ve heard a complaint about it.
• Awkward mechanisms for sequencing and/or working around recursion limitations.   For example, trying to determine sequence of a choreography requires temporary information sets and rescanning model to determine and process each successive node.
  Tefkat’s declarative ordering specification is very powerful but somewhat awkward to use since rules generally relate a single source object to a single target object, but to specify relative ordering you need two source objects and two target objects and references to the appropriate source and target features.

  We hope to include a mechanism to deal with the common simple case (for all source objects in this ordered collection, create a correspondingly ordered collection of target objects).

• Target instances are generally not acceptable to other processing engines (e.g., bpel, wsdl, j2ee, etc.).  These require xslt transforms to get them into an acceptable state.  This problem is joint tefkat/emf problem.
  Tefkat was designed for MOF-to-MOF (EMF-to-EMF) transformation so this was not a primary goal. However, to the extent that EMF supports transforming arbitrary XML documents (better if an XML Schema (XSD) is available), then so does Tefkat. There have been some substantial transformations written to transform eHealth records (based on OpenEHR) to XForms using EMF’s XSD support.
• Very limited expression evaluation, there is only simple arithmetic operators and a string concatenation capability.
  I’m not sure what extra expressions they would like, but Tefkat does support dynamically loaded functions via an Eclipse extension point so this is a hook that allows you to plug in arbitrary code. Note that Tefkat also supports various string splitting functions using regexps etc.
• No possibility to produce non-model target artifacts such as java source, text files, etc.
  And XSLT doesn’t allow you to transform non-XML documents — Tefkat is for model-to-model transformations. If you need model-to-text, then do a model-to-model transformation and write a pretty printer that gives you the right text.
• No mechanism to include defined “extensions” to models (e.g., an  “any”), such as the bpel extension or technology binding extensions to wsdl.
  Tefkat does have an any type and using reflection you can also match or create arbitrary objects. Again, I’m not sure what the real problem is.
• No extension mechanisms to work around any of the other problems.
  In fact, you can call arbitrary Java code from a Tefkat transformation, but it’s pretty hairy, undocumented, and a bit of a hack. As part of the planned support for staged transformations I hope to fix this.
• QVT not yet adopted by OMG.
  AFAIK, it’s in the final stages, but it’s a bit of a mess since it comprises three different models with the two declarative approaches being only partly integrated and the other (imperative approach) sitting off to the side.

  While I feel that the OMG really did/does need a QVT for their MDA to work, it really was too early to standardise on something when the requirements were not based on sufficient real-world experience.

• Not open source.
  It wasn’t, but as part of the wind-up of DSTC, Tefkat has been assigned to me on the condition that I Open Source it (which is what I always wanted). Keep your eye on http://sf.net/projects/tefkat.
• Provider (DSTC) no longer in business.
  No longer a relevant issue, see above.

The following are the issues with Tefkat that could not be resolved;

• Not accessible via ant, can not be composed into larger transformation chains.
• Can not reuse transformation fragments (e.g., no include/import capability)
• Requires fixed,static set of sources and targets, which are identified in a configuration model.  In practice, provisioning requires an arbitrary and dynamically determined set of sources and targets.
• Requires explicit tagging of each project with a tefkat nature, plus manual creation and maintenance of a configuration model.   
• No possibility for incremental target model updates.
• No possibility for determining scope of incremental source model updates.
• No default transformations.  For example, a copy of an instance of a source model to an instance of a target model requires a fully elaborated transformation, element by element, containment by containment, association by association, attribute by attribute.
• Parameterization of transform would only be possible via an additional source model.  Environmental state/properties are not accessible.
• Use of internal EMF api reduces portability across EMF versions.   Different versions of EMF alter behavior of QVT engine.
• Extremely poor performance.   Use of multiple elements in a “FOR ALL” may result in exponential number of WHERE evaluations across entire model.
• No recursively defined templates.
• Awkward mechanisms for sequencing and/or working around recursion limitations.   For example, trying to determine sequence of a choreography requires temporary information sets and rescanning model to determine and process each successive node.
• Target instances are generally not acceptable to other processing engines (e.g., bpel, wsdl, j2ee, etc.).  These require xslt transforms to get them into an acceptable state.  This problem is joint tefkat/emf problem.
• Very limited expression evaluation, there is only simple arithmetic operators and a string concatenation capability.
• No possibility to produce non-model target artifacts such as java source, text files, etc.
• No mechanism to include defined “extensions” to models (e.g., an  “any”), such as the bpel extension or technology binding extensions to wsdl.
• No extension mechanisms to work around any of the other problems.
• QVT not yet adopted by OMG.
• Not open source.
• Provider (DSTC) no longer in business.