QVTd Relation Overriding

The QVT specification has a relatively clear specification that QVTr relation may override, but no clues as to how this is mapped to QVTc that has no overrides concrete syntax, even though it inherits an overrides capability from QVTb.

This working document considers how overriding might be supported. It takes over from

• https://bugs.eclipse.org/bugs/show_bug.cgi?id=508267 [qvts] Introduce MicroMapping Alternator/Switch
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=515327 [qvtc] Support overrides / refines

QVTc Choices

QVTc refinement syntax is an additive capability and therefore not suitable for implementing the QVTr replacement semantics of QVTr overrides.

We could add overrides syntax to semantics to QVTc, which then passes the buck to QVTi. But since we already need an 'alternator' to dispatch multiple similar but differently predicated mappings efficiently, we may be able to kill two birds with one stone.

QVTc is relatively simple. It solves the mapping sequencing problem by inter-trace class references/dependencies. Can it solve the overrides problem as-is? Let's go with this.

The low level / run-time mechanism

Temporarily ignoring the additional complexities of multi-headed mappings, when an element is dequeued from a Connection, it is dispatched to all relevant mappings. This remains true for overrides. Predicates and type guards will suppress most irrelevant invocations, but we must suppress overrides. There will often be only one appropriate mapping, but we cannot avoid the possibility that the input model has new compound types that are multiply matched. We cannot avoid a multiplicity of matches and a lattice of fall-backs for failed predicates.

The original motivation for an alternator was to avoid repetition. If the alternator hoists all predicate functionality from all dispatch candidates, we maximize sharing, and can resolve all the fall-backs before 'returning' with the list of actual dispatches.

Perhaps the alternator is a function that is invoked as the predicate of each override. Possible because the failed predicates should participate in a decision tree. But how top pass context.

If the alternator is a mapping,it has a trace class that can have all the required shared content. The overrides just predicate the alternator-trace-class and its magic decision variables. Simple override choices may use a simple alternator class to avoid bloating the alternator trace withe all the context for every awkward choice. The alternator therefore conditionalizes its realized trace variable.