QVT14 — QVTr: checkonly confusion

The descriptions regarding checkonly and enforce are incomplete and the examples are misleading.

When a domain is selected as a target, there are three execution possibilities.

• the target is enforced - created/replaced/updated/...
• the target is checked - compared
• the target selection is illegal - an unsupported direction

The illegal state is never described, but is at the heart of a unidirectional transformation for which, as in RelToCore, the source-only domain has no checkonly/enforce and the target-only domain has enforce.

In contrast almost all of the UML2RDBMS examples have the uml domain marked as checkonly, which requires that an execution from RDBMS to check a pre-existing UML is permissible. This requires that the transformation is genuinely bidirectional although by using checkonly rather than enforce the programmer has unhelpfully prohibited the to-UML result from being persisted.

It is doubtful that checkonly has any value at all as a concrete syntax / abstract syntax annotation. Surely a plausible output domain is always enforce; it is the way in which the transformation is invoked that configures whether the enforce creates/replaces/updates/compares/checks... ? Perhaps it is the redundancy of checkonly that has led to the misunderstandings exemplified by the UML2RDBMS example that checkonly marks the input of a unidirectional relation.

Actions required:

• describe the third illegal target state
• change UML2RDBMS examples to genuinely unidirectional
• provide a bidirectional example
• deprecate checkonly