Review of BXtendDSL solution

[fjouault]

Description

This solution consists in a declarative part (in Class2Relational.bxtend), which describes high-level mappings, and an imperative part (in the .xtend files of folder rules), which defines (in hook methods) how mappings are actually implemented. Although BXtendDSL supports bidirectionality, this solution only supports incrementality, as required by the cae.

Features provided by BXtendDSL

• A single declarative specification automates multiple things:
  • Each property-level mapping specifies the source properties that are necessary to compute a target property. The framework is then able to automatically re-execute the imperative hook methods when necessary.
  • The framework also helps the programmer by automatically supporting traceability.
• The power of the xtend GPL is available for complex tasks.

Possible incrementality limitations

Incrementality seems to be relatively coarse-grained. Whole hook methods are a priori re-executed if just one property changes (see Question 3 below). This is not really a problem in simple transformations such as Class2Relational, but could become expensive in more complex ones.

Questions

1. What does on demand mean in Section 2 of the paper? Does it mean that the whole transformation is executed on-demand? That propagation happens on-demand? Or that the resulting models are lazy/reactive (i.e., parts are computed on-demand)?
2. What is the relation between BXtend & BXtendDSL? It does not seem that BXtendDSL imports any BXtend-specific classes. Is it a new implementation inspired from BXtend? If BXtend is the GPL version of BXtendDSL, it would be interesting to have a BXtend solution as well.
3. How incremental are hook methods?
   • Is findIntegerDatatype incremental? For instance, what happens if we change the names of the String & Integer data types?
   • Is filterAtt incremental? For instance, what happens if att.isMultiValued is changed, or if att.type changes from a DataType to a Class?
   • How incremental is colFrom (Listing 4)? Will it be able to reuse columns or will it recreate them if, for instance, the attribute name changes?
4. Any reason why findIntegerDatatype is repeated in several classes? Could it be reused, e.g., by making it static?
5. The paper states that rule execution order is important for trace resolution. What happens when
   there are some circular dependencies between rules? Or when incrementality makes things happen out of order (e.g., if the data types are added to the model later)?
6. Does the generator preserve manually modified code, in case one wants to modify the .bxtend file?

Remarks about the paper

• The introduction could be a bit more specific to BXtendDSL.
• It could be useful to have a correspondence between Fig. 1, and the source folders/files as well as the framework packages, especially because naming does not always make things clear (e.g., BXtendDSL Imperative files seem to be written in the xtend GPL).
• Typos
  • “exeuction” -> “execution”
  • --> is described as –> (i.e., with a en dash), maybe because LaTeX rewrote -- into –, which \verb could hopefully prevent.

Remarks about the code

• There does not seem to be any complexity annotation, although this is required for evaluation (see case paper). Such annotations should at least be provided for the non-generated parts (i.e., the .bxtend file, the hook method bodies, and the extra helper methods, such as findIntegerDataType).