QVT13 — QVTc/QVTr: View/Transformation discrepancy

"The starting point is a major flaw in all three QVT languages at present and enabled Perdita Stevens to correctly conclude in http://www.springerlink.com/content/9x368617317l3q87/ that QVTr and QVTc are incompatible. QVT currently provides no way to distinguish whether for instance a check-mode transformation is a query of whether a transformed input pattern can be discovered in the output (e.g. a database lookup), or a validation that the transformed input exactly matches the output (e.g. an already transformed check). Both facilities are useful and so when a QVT transformation is invoked the invoker needs to specify what I call the 'rooting' condition in addition to the direction

Unclear transformation rooting condition

"The starting point is a major flaw in all three QVT languages at present and enabled Perdita Stevens to correctly conclude in http://www.springerlink.com/content/9x368617317l3q87/ that QVTr and QVTc are incompatible. QVT currently provides no way to distinguish whether for instance a check-mode transformation is a query of whether a transformed input pattern can be discovered in the output (e.g. a database lookup), or a validation that the transformed input exactly matches the output (e.g. an already transformed check). Both facilities are useful and so when a QVT transformation is invoked the invoker needs to specify what I call the 'rooting' condition in addition to the direction

Discussion

We need a much simpler principled exposition of the intent of QVTc/QVTr. Since Perdita has correctly come to such unwelcome conclusions, we clearly have a problem. The new statement should be uncontroversial and therefore provide a reference against which subsequent text can be assessed.

The following is perhaps what is needed, but needs more discussion with QVTr users and prototyping of its implications.

In Section 6.3 replace

The semantics of the Core language (and hence the Relations language) allow for the following execution scenarios:
• Check-only transformations to verify that models are related in a specified way.
• Single direction transformations.
• Bi-directional transformations. (In fact more than two directions are possible, but two is the most common case.)
• The ability to establish relationships between pre-existing models, whether developed manually, or through some other
tool or mechanism.
• Incremental updates (in any direction) when one related model is changed after an initial execution.
• The ability to create as well as delete objects and values, while also being able to specify which objects and values must
not be modified.

by

A Declarative QVT transformation capability establishes a correspondence between source objects in one or more source models and transformed objects in one or more transformed models. The correspondence may be used to check or enforce a view of, or a transformation to, target objects in one or more target models.

The correspondence takes the form of trace data comprising a set of trace records. Each trace record identifies a relationship to one or more transformed objects from, one or more, source or transformed, objects or values. The production of each transformed object is traced by exactly one trace record. The trace data includes relationships for all satisfied constraints imposed by the language constructs that express the transformation program. No relationships for satisfiable constraints are omitted from the trace data.

In practice a Core language (and hence the Relations language) transformation is executed after a form, mode and direction have been selected.

There are two main forms of QVT execution:

• For a Transformation execution, there is an exactly 1:1 mapping between the transformed objects and the target objects.

• For a View execution, there is an exactly 1:1 mapping between the transformed objects and the target objects in the view. There may be further target objects outside the view that are unaffected by the execution.

Additionally, for a Query execution, an OCL query is executed on the trace data. No actual target models are required.

There are three modes of execution:

• An enforced View or Transformation execution coerces the target objects to correspond to the transformed objects. (This is most simply achieved by model replacement, but may be realized by executing a series of changes so that desirable extra-model considerations such as xmi:id preservation or minimal database activity are accommodated.)

• A check execution is a degenerate Query execution that just returns true or false according to the existence of the trace data. (An optimized execution capability may bypass the creation of the transformed objects and look for correspondence between source and target objects directly.)

• An update Query, View or Transformation execution compares an old correspondence between source objects and transformed objects with a new correspondence between changed source objects and correspondingly changed transformed objects. The correspondence changes may be used to enforce or check for corresponding creations, deletions and updates in the target objects.

Additionally an in-place update View or Transformation execution shares source and target models and so each source object is coerced to correspond to its transformed equivalent. (This can be naively achieved by model copy. An optimized execution may bypass the creation of the transformed objects by performing each source read before any corrupting write.)

The declarative transformation languages do not have fixed sources and targets, rather they have multiple domains some of which may be designated sources and others as targets. The direction of the transformation is chosen by selecting the domain to be used as a target.

• A unidirectional transformation has just a single choice of direction since only one domain is able to be used as the target

• For a bi-directional, and more generally a multi-directional transformation, the domain used as the target may be selected

In practice it is often difficult to satisfy the bijective requirements of bidirectional execution and so many transformations are just unidirectional.