Issue 18572: QVT atomicity (qvt-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Clarification Severity: Minor Summary: Clause 7.7 mandates fixed-point semantics for in-place transformations. Please ask my bank to use a repeat-until-no-change in-place transformation for my next pay cheque: new-balance = old-balance + deposit. More seriously, the repeat is at the relation level, so if there are multiple applicable relations, the in-place result is specified to experience multiple updates in an indeterminate order. If relation A and then relation B are repeated to exhaustion, is relation A repeated again to accommodate relation B's changes? Start again. QVTr and QVTc are declarative, therefore they express a single complex truth about the final outputs with respect to the original inputs. There are no observable intermediate steps. It is the responsibility of the transformation engine to ensure that the multiple actual output changes are observed as a single atomic transaction. In particular for in-place transformations, the engine must ensure that no input value is accessed after it is updated for output. In regard to fixed-point semantics, repetition can only be determinate if it is the entire tranformation that is repeated, and whether to do so would seem to be a legitimate execution option. Therefore QVT should either not specify repetition at all, leaving it to the invoking engine, or specify it as an invocation option for a RelationCallExp. If an in-place transformation does perform fixed-point repetition at the transformation level, it would seem that the whole repetition should still be a single atomic transaction so that outputs are never observable in an inconsistent partially transformed state between iterations. The engine must therefore iterate over candidate outputs rather than actual outputs. Resolution: Fixed point semantics can be achieved by a has-it-changed loop. Revised Text: In 7.7 In-place Transformations replace A transformation may be considered in-place when its source and target candidate models are both bound to the same model at runtime. The following additional comments apply to the enforcement semantics of an inplace transformation: • A relation is re-evaluated after each enforcement-induced modification to a target pattern instance of the model. • A relation’s evaluation stops when all the pattern instances satisfy the relationship. by A transformation may be considered in-place when one or more source models are bound to one or more target models at runtime. Execution proceeds as if the source and target models are distinct with an atomic update of non-distinct models occurring on completion of the transformation. This implies that an implementation that operates in-place must take copies of the old state to avoid confusion with updated new state. Execution of a transformation should return a Boolean status to indicate whether any changes were made to target models. This status enables transformation applications to repeat execution until no changes occur where that is appropriate for the application. Actions taken: March 21, 2013: received issue July 15, 2014: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 21 Mar 2013 02:08:34 -0500 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAR0YqyA= X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: Specification: QVT Section: 7.7 FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: 19 Title: QVT atomicity Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Description: Clause 7.7 mandates fixed-point semantics for in-place transformations. Please ask my bank to use a repeat-until-no-change in-place transformation for my next pay cheque: new-balance = old-balance + deposit. More seriously, the repeat is at the relation level, so if there are multiple applicable relations, the in-place result is specified to experience multiple updates in an indeterminate order. If relation A and then relation B are repeated to exhaustion, is relation A repeated again to accommodate relation B's changes? Start again. QVTr and QVTc are declarative, therefore they express a single complex truth about the final outputs with respect to the original inputs. There are no observable intermediate steps. It is the responsibility of the transformation engine to ensure that the multiple actual output changes are observed as a single atomic transaction. In particular for in-place transformations, the engine must ensure that no input value is accessed after it is updated for output. In regard to fixed-point semantics, repetition can only be determinate if it is the entire tranformation that is repeated, and whether to do so would seem to be a legitimate execution option. Therefore QVT should either not specify repetition at all, leaving it to the invoking engine, or specify it as an invocation option for a RelationCallExp. If an in-place transformation does perform fixed-point repetition at the transformation level, it would seem that the whole repetition should still be a single atomic transaction so that outputs are never observable in an inconsistent partially transformed state between iterations. The engine must therefore iterate over candidate outputs rather than actual outputs.