Issue 15411: Unclear transformation rooting condition (qvt-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: "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 Resolution: 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 [1]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. ---------------------------------------------------------------------------------------- [1] http://www.springerlink.com/content/9x368617317l3q87/ Revised Text: Actions taken: August 10, 2010: received issue December 22, 2015: Deferred March 29, 2016: closed issue Discussion: This requires some research work. Disposition: Deferred End of Annotations:===== ubject: Question on QVT Relation To: qvt-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 9 Aug 2010 11:19:42 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 08/09/2010 11:19:43 Hello All, I noticed that the top relations in a QVT Relational transform are NOT ordered. Is there a prescribed algorithm for ordering them an executing engine should use ? Does the engine have to analyze the dependencies between them and go from the least depedent to the most depedent? Please advise... Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAHrMX0zUnw4T/2dsb2JhbACfYoFUxCSDCoIwBA Date: Mon, 09 Aug 2010 17:41:15 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: Maged Elaasar CC: qvt-rtf@omg.org Subject: Re: Question on QVT Relation Hi Maged I think not-ordered is correct. Philosophically QVTr should just do the right thing, so following dependencies is a necessary aspect of right. If the ordering is material, the transformation would not be purely declarative; the ordering would be an imperative semantics. The engine should be free to use whatever algorithm it likes to produce the unique observable result. Any implied algorithm in the specification should be for exposition purposes only. Regards Ed Willink On 09/08/2010 16:19, Maged Elaasar wrote: Hello All, I noticed that the top relations in a QVT Relational transform are NOT ordered. Is there a prescribed algorithm for ordering them an executing engine should use ? Does the engine have to analyze the dependencies between them and go from the least depedent to the most depedent? Please advise... Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3059 - Release Date: 08/08/10 18:57:00 From: "Wartik, Steven P \"Steve\"" To: "'Ed Willink'" , Maged Elaasar CC: "qvt-rtf@omg.org" Date: Mon, 9 Aug 2010 21:53:44 -0400 Subject: RE: Question on QVT Relation Thread-Topic: Question on QVT Relation Thread-Index: Acs34f0IGsUTSfbARXCySgu80l9cDwATIz7w Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, Are you saying that the QVTr requires the relations graph to be a tree and not a forest? I had not seen that in the specification and always assumed specifying the starting relation was a necessary input to performing a transformation. Regards, Steve Wartik From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, August 09, 2010 12:41 PM To: Maged Elaasar Cc: qvt-rtf@omg.org Subject: Re: Question on QVT Relation Hi Maged I think not-ordered is correct. Philosophically QVTr should just do the right thing, so following dependencies is a necessary aspect of right. If the ordering is material, the transformation would not be purely declarative; the ordering would be an imperative semantics. The engine should be free to use whatever algorithm it likes to produce the unique observable result. Any implied algorithm in the specification should be for exposition purposes only. Regards Ed Willink On 09/08/2010 16:19, Maged Elaasar wrote: Hello All, I noticed that the top relations in a QVT Relational transform are NOT ordered. Is there a prescribed algorithm for ordering them an executing engine should use ? Does the engine have to analyze the dependencies between them and go from the least depedent to the most depedent? Please advise... Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3059 - Release Date: 08/08/10 18:57:00 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAD+eYExUXeb0/2dsb2JhbACBRJ4wBV1xwTSDCoIwBA Date: Tue, 10 Aug 2010 08:33:49 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 CC: "qvt-rtf@omg.org" Subject: Re: Question on QVT Relation Hi Steven My comments are based on what I think should be right in a purely declarative sense. For the most part I find that the core principles I determined for UMLX are the same as those of QVTr, although in a couple of areas such as Collection matches are not. Simplistically, I take the view that all possible input patterns that fully and maximally satisfy all constraints are transformed. The QVTr language and meta-models provide an effective way of expressing useful constraints in a compact manageable fashion. I would certainly expect QVTr to work on forests, both as the user model and as the QVTr transformation; not sure which you meant by 'relations graph'. If (tree-based) forests are really the case then there can be no cross-dependencies so any execution ordering should yield the same results. However in the presence of cross-dependencies this may not be the case, and so only some orderings will be legal. These dependencies should only be observable via the ordering of output and intermediate collections. In the case of an in-place transformation, further dependencies will require that all old elements are read before updated with new elements. I don't think that any observations based on the side-effects of black boxes are valid. 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. Regards Ed Willink On 10/08/2010 02:53, Wartik, Steven P "Steve" wrote: Ed, Are you saying that the QVTr requires the relations graph to be a tree and not a forest? I had not seen that in the specification and always assumed specifying the starting relation was a necessary input to performing a transformation. Regards, Steve Wartik From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, August 09, 2010 12:41 PM To: Maged Elaasar Cc: qvt-rtf@omg.org Subject: Re: Question on QVT Relation Hi Maged I think not-ordered is correct. Philosophically QVTr should just do the right thing, so following dependencies is a necessary aspect of right. If the ordering is material, the transformation would not be purely declarative; the ordering would be an imperative semantics. The engine should be free to use whatever algorithm it likes to produce the unique observable result. Any implied algorithm in the specification should be for exposition purposes only. Regards Ed Willink On 09/08/2010 16:19, Maged Elaasar wrote: Hello All, I noticed that the top relations in a QVT Relational transform are NOT ordered. Is there a prescribed algorithm for ordering them an executing engine should use ? Does the engine have to analyze the dependencies between them and go from the least depedent to the most depedent? Please advise... Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3059 - Release Date: 08/08/10 18:57:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3060 - Release Date: 08/09/10 07:35:00 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FABqkYEzUnw4U/2dsb2JhbACBRJ4wYnHBOoU6BA Date: Tue, 10 Aug 2010 08:59:11 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: Juergen Boldt Subject: Re: Question on QVT Relation not an issue, I assume? Indeed until: "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." which I don't seem to have got round to raising before. Please raise an Issue titled: "Unclear transformation rooting condition" Ed From: "Rouquette, Nicolas F (316A)" To: Ed Willink CC: "qvt-rtf@omg.org" Date: Tue, 10 Aug 2010 09:07:11 -0700 Subject: Re: Question on QVT Relation Thread-Topic: Question on QVT Relation Thread-Index: Acs4pheFOO75X1asQTa4ww2pJOWBDg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Ed, I agree that for QVTc and QVTr, a well-formed transformation should have an unambiguous declarative meaning, one that does not depend on any particular ordering for the execution of the rules. That is, if an engine makes a poor choice of the order in which it executes the rules, it may reach a deadend where the transformation fail and may have to backtrack to use a different ordering. For QVTo, all execution starts from the "main()" operation -- see QVT clause 8.1.1 - Nicolas. On Aug 10, 2010, at 12:33 AM, Ed Willink wrote: Hi Steven My comments are based on what I think should be right in a purely declarative sense. For the most part I find that the core principles I determined for UMLX are the same as those of QVTr, although in a couple of areas such as Collection matches are not. Simplistically, I take the view that all possible input patterns that fully and maximally satisfy all constraints are transformed. The QVTr language and meta-models provide an effective way of expressing useful constraints in a compact manageable fashion. I would certainly expect QVTr to work on forests, both as the user model and as the QVTr transformation; not sure which you meant by 'relations graph'. If (tree-based) forests are really the case then there can be no cross-dependencies so any execution ordering should yield the same results. However in the presence of cross-dependencies this may not be the case, and so only some orderings will be legal. These dependencies should only be observable via the ordering of output and intermediate collections. In the case of an in-place transformation, further dependencies will require that all old elements are read before updated with new elements. I don't think that any observations based on the side-effects of black boxes are valid. 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. Regards Ed Willink On 10/08/2010 02:53, Wartik, Steven P "Steve" wrote: Ed, Are you saying that the QVTr requires the relations graph to be a tree and not a forest? I had not seen that in the specification and always assumed specifying the starting relation was a necessary input to performing a transformation. Regards, Steve Wartik From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, August 09, 2010 12:41 PM To: Maged Elaasar Cc: qvt-rtf@omg.org Subject: Re: Question on QVT Relation Hi Maged I think not-ordered is correct. Philosophically QVTr should just do the right thing, so following dependencies is a necessary aspect of right. If the ordering is material, the transformation would not be purely declarative; the ordering would be an imperative semantics. The engine should be free to use whatever algorithm it likes to produce the unique observable result. Any implied algorithm in the specification should be for exposition purposes only. Regards Ed Willink On 09/08/2010 16:19, Maged Elaasar wrote: Hello All, I noticed that the top relations in a QVT Relational transform are NOT ordered. Is there a prescribed algorithm for ordering them an executing engine should use ? Does the engine have to analyze the dependencies between them and go from the least depedent to the most depedent? Please advise... Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3059 - Release Date: 08/08/10 18:57:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3060 - Release Date: 08/09/10 07:35:00