Issue 18572: QVT atomicity (qvt-rtf) Source: Nomos Software (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: Revised Text: Actions taken: March 21, 2013: received 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.