Issue 15411: Unclear transformation rooting condition (qvt-rtf) Source: Nomos Software (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: Revised Text: Actions taken: August 10, 2010: received issue Discussion: 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