logseq/pages/@02-16-JSSOFTWARE-D-23-01182.md

institution:: SSRN tags:: #zotero date:: 2024 report-type:: preprint extra:: DOI: 10.2139/ssrn.4686181 title:: @02-16-JSSOFTWARE-D-23-01182 item-type:: report access-date:: 2024-02-26T21:05:30Z original-title:: 02-16-JSSOFTWARE-D-23-01182 language:: en url:: https://www.ssrn.com/abstract=4686181 short-title:: Bit authors:: Xiao He, Tao Zan library-catalog:: DOI.org (Crossref) links:: Local library, Web library

• Abstract
  • Model-driven development is a model-centric software development paradigm that automates the development process by converting high-level models into low-level code and documents. To maintain synchronization between models and code/documents—which can evolve independently—this paper introduces BIT, a bidirectional language that can serve as a conventional template language for model-to-text transformations. However, a BIT program can function as both a printer, generating text by filling template holes with values from the input model, and a parser, putting parsed values back into the model. BIT comprises a surface language for better usability and a core language for formal definition. We define the semantics of the core language based on the theory of bidirectional transformation, and provide the translation from the surface to the core. We present the proof sketch of the well behavedness of BIT as a formal evidence of soundness. We also conduct two preliminary case studies to empirically demonstrate the expressiveness of BIT. Based on the proof and the case studies, BIT covers the major features of existing template languages, and offers sufficient expressiveness to define real-world model-to-text transformations that can be executed bidirectionally and incrementally.

• Attachments

  • He e Zan - 2024 - Bit A Template-Based Approach to Incremental and .pdf {{zotero-imported-file Y5NSDNBL, "He e Zan - 2024 - Bit A Template-Based Approach to Incremental and .pdf"}}
• institution:: SSRN tags:: #zotero date:: 2024 report-type:: preprint extra:: DOI: 10.2139/ssrn.4686181 title:: @02-16-JSSOFTWARE-D-23-01182 item-type:: report access-date:: 2024-02-26T21:05:30Z original-title:: 02-16-JSSOFTWARE-D-23-01182 language:: en url:: https://www.ssrn.com/abstract=4686181 short-title:: Bit authors:: Xiao He, Tao Zan library-catalog:: DOI.org (Crossref) links:: Local library, Web library
• Abstract
  • Model-driven development is a model-centric software development paradigm that automates the development process by converting high-level models into low-level code and documents. To maintain synchronization between models and code/documents—which can evolve independently—this paper introduces BIT, a bidirectional language that can serve as a conventional template language for model-to-text transformations. However, a BIT program can function as both a printer, generating text by filling template holes with values from the input model, and a parser, putting parsed values back into the model. BIT comprises a surface language for better usability and a core language for formal definition. We define the semantics of the core language based on the theory of bidirectional transformation, and provide the translation from the surface to the core. We present the proof sketch of the well behavedness of BIT as a formal evidence of soundness. We also conduct two preliminary case studies to empirically demonstrate the expressiveness of BIT. Based on the proof and the case studies, BIT covers the major features of existing template languages, and offers sufficient expressiveness to define real-world model-to-text transformations that can be executed bidirectionally and incrementally.

• Attachments

  • He e Zan - 2024 - Bit A Template-Based Approach to Incremental and .pdf {{zotero-imported-file R695QDD8, "He e Zan - 2024 - Bit A Template-Based Approach to Incremental and .pdf"}}
• Notes

  • “To maintain synchronization between models and code/documents—which can evolve independently—this paper introduces BIT, a bidirectional language that can serve as a conventional template language for modelto-text transformations.” (He e Zan, 2024, p. 0) #f0ff00 Does it solve the problem with target protected areas?

  • “However, a BIT program can function as both a printer, generating text by filling template holes with values from the input model, and a parser, putting parsed values back into the model.” (He e Zan, 2024, p. 1) #f0ff00 Is TCS in the related work?

  • “very few solutions for synchronizing models and text.” (He e Zan, 2024, p. 2) #f0ff00 what about boomerang? And TCS? I would have introduced a motivating example to show when and how existing works fall short.

  • “Bidirectional transformation (BX) [22, 23, 24, 25, 26, 27, 28] can serve as the foundation of data synchronization. A BX program is a single specification that can be consistently evaluated in” (He e Zan, 2024, p. 3) #f0ff00 have you considered JTL, QVT relation, etc.?

  • “their approach is limited code generation from Ecore models and is not generally applicable.” (He e Zan, 2024, p. 3) #f0ff00 do you plan to propose an approach that works on any ecosystem further than Ecore?

  • “two challenges” (He e Zan, 2024, p. 3) #f0ff00 it is nessary to give evidence of such issues by showing an explanatory examples that cannot be managed by existing appoaches.

  • “As for control directives, Xtend templates support loops (e.g., lines 6–14), conditions (e.g., lines 7–10), and assignments (e.g., lines 5 and 8). Within an Xtend template, other templates may be invoked.” (He e Zan, 2024, p. 5) #00b036

  • “Figure 3: Demonstration of BIT template (colored background shows the changed text layout)” (He e Zan, 2024, p. 6) #f0ff00 what about the attribute no? I think it should be in the parsed output, isn't it?

  • “with a lexical rule that guides our approach in the parsing mode. For example, «no|INT» in line 10 indicates that this hole will be filled with a string that is produced by the expression no and conforms to lexical rule INT, where the rule is defined by regular expression -?[0-9]+” (He e Zan, 2024, p. 6) #00b036

  • “infer a lexical rule.” (He e Zan, 2024, p. 6) #f0ff00 how? Is there any default rule that is applied?

  • “of the third paragraph will be "Appreciation", rather than "appreciation", because the first character in the old head is capitalized as "S"” (He e Zan, 2024, p. 7) #f0ff00 *that's not clear. What about the "Some text" that is ignored and "Thanks" is instead in the output.

    Moreover the management of capital letters is not clear.*

  • “The BIT approach” (He e Zan, 2024, p. 7) #f0ff00 very much similar to QVT relation and QVT Core. It is necessary to discuss and compare BIT with respect to QVT technologies.

  • “Figure 5: Essential grammar of the surface language” (He e Zan, 2024, p. 8) #f0ff00 the full grammar is not needed here. You can move it as an appendix and instead you can discuss in this section the peculiar aspects of the language by means of representative and illustrative cases.

  • “LexRule is a regular expression or a rule name bound to a regular expression, e.g., ID refers to [_a-zA-Z][_a-zA-Z0-9]*” (He e Zan, 2024, p. 9) #f0ff00 it is necessary to make explicit what's the relation of what you specify with rules and the corresponding metaclasses, which are supposed to type the instances that can be created by parsing elements with respect to such rules.

  • “Case studies” (He e Zan, 2024, p. 26) #f0ff00 This section needs to be improved by presenting a proper evaluation section, which starts by describing the research questions that the authors want to answer by mens of the performed evaluation. The way related works have been identified is also important. For instance, I don't see among them existing works like QVT, JTL, TCS.

  • “General information of the benchmark examples” (He e Zan, 2024, p. 29) #f0ff00 *Instead of presenting the table in terms of examples, I suggest to reorganise the table and thus, the corresponding text, by making explicit the peculiar cases that existing approach have issues in supporting them. Talking about examples is not a proper way to sustain a strong and organized discussion. Thus the examples column needs to be properly refined and decomposed with respect to their peculiar characteristcs.

    Moreover, I would define a conceptual framework to compare existing approach by identifying peculiar features and discussing their support by the analysed approaches. Such an analysis should be presented earlier in the paper, when motivating the needs for a novel BX template language.

    I don't see in the table Boomerang neither. If it is because it is not Ecore based, then "Platform" is one of the different dimensions that should be considered for the comparison.*

  • “major features of” (He e Zan, 2024, p. 30) #f0ff00 what are they? see my previous comments about the conceptual framework for comparison.

  • “Left Recursions. Parsers derived from BIT templates cannot handle left recursions. Figure 14 shows a concrete example template containing left recursion. Currently, the tool support of BIT cannot check left recursion statically. It will be our future work to investigate how to detect left recursions in templates by adopting existing techniques in the field of compilers. #[[ #foreach ($woogie in $boogie) nothing will happen to $woogie” (He e Zan, 2024, p. 31) #f0ff00 left recursion is another dimension.

  • “Efficiency” (He e Zan, 2024, p. 31) #f0ff00 this is another possible dimension but needs to be elaborated more in order to present the problems related to efficiency, and talk existing works also with respect to such a dimension.

  • “Specifically” (He e Zan, 2024, p. 32) #f0ff00 what about Epsilon ECL?

  • “Our previous work [20] on bidirectional model transformation proposed a putback-based language which enabled us to define a backward transformation from which a well-behaved BX can be derived.” (He e Zan, 2024, p. 32) #f0ff00 have you compared with your previous work?

  • “a template language for code matching and rewriting. In matching process, Comby interprets a code template and” (He e Zan, 2024, p. 33) #f0ff00

  • “verbose text and template extension.” (He e Zan, 2024, p. 34) #f0ff00 see the comparison comment above.