Miscellaneous-B

Here are some quick responses to this paper:

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