Transformation Tool Contest 2011
Gábor's QVTR-XSLT review
1) *** SUBMISSION TITLE: Solving the Hello World Case with QVTR-XSLT
Li Dan, Thursday, 02 June 2011 18:58
Hi, Gábor'. Thanks a lot for review. I just find time to test the SHARE again. All transformations execute fine.
To run the generated XSLT stysheet, an including XSLT file is required. So you should either generate the XSLT into the "transformations" directory, or check the "copy inclding XSLT files" in the code generator. Actually, it is natural to expect the transformations to be runing from the "transformations" directory.
-> Does the solution to the edge reversal task handle dangling edges properly?
Yes. It can even handle isolated edges.
-> The solution is composed from three standard-based languages: QVTr (graphical), OCL, XSL; the former two is translated to the latter by the toolchain. Some guidelines are given on the kind of problems where OCL is better than QVTr, but no indication is given when to use XSLT directly.
XSLT is the background execution language. In the surface, we use it only when we need a so called "blackbox implementation" of a QVT relation (function).
-> For example, can't GetLoopingEdges (Fig. 15) simply be written with 'src' and 'trg' pointing to the same :Node? Constructs like "where=results=eds..." are also somewhat confusing at first, though they can be understood with some effort.
No. QVT uses key to identify elements. We have to tell they have the same key. And the "result" is a strandard variable in OCL for returning values.
-> There is also no explanation given why GetAllCircleNodes() isn't just simply a graphical QVT query with three nodes forming a circle. Is the purpose of the XSLT implementation to show that general k-circles can also be formalized in the tool? Which is indeed a quite powerful feature, of course; though it seems pretty difficult to implement the task directly in XSLT
Yes, we can count k-circles by putting the k-1 as the third parameter of function GetCircleNodes().
Actually, XSLT can do every thing if you used to think in XSLT.
-> XSL function CalcuMatch (Fig. 20) does not seem to be referenced anywhere in the paper, and does not use its declared parameters. However, it uses some other undefined variables that could be parameters. At the same time, getCircleNodes() is not defined anywhere. Can we assume that Fig. 20 is really getCircleNodes(), just mislabeled
Yes, you are right. We make a mistake. This should be the function getCircleNodes().
-> Not being an expert on QVT, some smaller details left me wondering; therefore more explanation in the paper or in the appendix would have been useful. E.g. in Fig. 22, the same identifier 'tn' is used in both domains. Does this mean that the node will be copied? If yes, why is there a separate NodeToNode rule? On the other hand, why isn't NodeToNode referenced in the 'when' part of EdgeToEdge? The same holds for Fig. 25.
In QVT, a variable in source domain (left) means binding a model element to the variable, and the variable in target domain (right) means assigning value of the variable to the model element. In this transformation, we use one rule NodeToNode copying nodes, and rule EdgeToEdge to handle edges. Since a node is supported to create in rule NodeToNode, then the target domain of EdgeToEdge only create a link to the node. Of cource you can put a relation call to NodeToNode in when clause of rule EdgeToEdge to enforce a node has been created before it can be referenced.