type:: [[REVIEWS]]
tags::
year:: 2024
venue:: [[JSS]]
full-title:: BIT: A template-based approach to incremental and bidirectional model-to-text transformation
date-start:: [[17-01-2024]] - 16:58
date-submitted::
external-links::
status:: [[DONE]] 
deadline-submission:: [[16-02-2024]]
file:: [He e Zan - 2024 - Bit A Template-Based Approach to Incremental and .pdf](zotero://select/library/items/R695QDD8) {{zotero-imported-file R695QDD8, "He e Zan - 2024 - Bit A Template-Based Approach to Incremental and .pdf"}}
parent::
todoist:: https://app.todoist.com/showTask?id=7605145256

	- ### [[Highlights]]
		- ((65e1a11f-e438-4b94-a86e-b7567b37a088))
			- Incrementality should be better explained.
		- ((65e1a25a-f313-47f7-94e7-269d49153c3e))
			- Depending on the cases, it can be that m and m' are the same. so shouldn't be that m=m' in the equation?
		- ((65e1a32f-77b0-4509-b7a4-22527e368155))
			- if needed
		- ((65e1a3d8-ac28-4ff9-972e-4de53d273654))
			- This is a strong statement and should be more elaborated in the text. It is also important to discuss what are the practical implications of such an assumption.
		- ((65e1a5ef-fd36-41d2-a12d-6de436c1ca0d))
			- In the formalizations given at page 16, I think it is also important to add the formalization of the concept pattern, which is only mentioned and used by the different primitives. By giving such formulation it gets clear how
	- “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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=1&annotation=YXE48ENQ)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=2&annotation=RTTI8HIG)) #f0ff00  
	  *Is TCS in the related work?*
	- “very few solutions for synchronizing models and text.” ([He e Zan, 2024, p. 2](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=3&annotation=SDDUGDW5)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=4&annotation=XLERBGRH)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=4&annotation=J5UH4YXD)) #f0ff00  
	  *do you plan to propose an approach that works on any ecosystem further than Ecore?*
	- “two challenges” ([He e Zan, 2024, p. 3](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=4&annotation=83DTSHC8)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=6&annotation=PQY3QEWW)) #00b036
	- “Figure 3: Demonstration of BIT template (colored background shows the changed text layout)” ([He e Zan, 2024, p. 6](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=7&annotation=46LBCIAY)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=7&annotation=SUX5CPI7)) #00b036
	- “infer a lexical rule.” ([He e Zan, 2024, p. 6](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=7&annotation=VZ3SULBX)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=8&annotation=C8YQUMZG)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=8&annotation=3UDGBKS9)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=9&annotation=AG2FZ2GP)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=10&annotation=3UZ4LM38)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=27&annotation=Q2CLHRFM)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=30&annotation=8C6NLPR5)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=31&annotation=AYXXN4LJ)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=32&annotation=HK4C8IZI)) #f0ff00  
	  *left recursion is another dimension.*
	- “Efficiency” ([He e Zan, 2024, p. 31](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=32&annotation=3D3CFPH6)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=33&annotation=JT5I8KSR)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=33&annotation=7ZXAILQG)) #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](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=34&annotation=TSG8IVK4)) #f0ff00
	- “verbose text and template extension.” ([He e Zan, 2024, p. 34](zotero://select/library/items/6LRHKSQJ)) ([pdf](zotero://open-pdf/library/items/R695QDD8?page=35&annotation=4AHEAG99)) #f0ff00  
	  *see the comparison comment above.*
	- ### [[Comments]]
		- **SUMMARY**: BIT is a bidirectional language that helps with model-to-text transformations in Model-Driven Development. It acts as a template language, ensuring synchronization between high-level models and low-level code/documents that can evolve separately. BIT includes a surface language and a core language. The paper establishes the semantics of the core language based on bidirectional transformation theory and offers a proof sketch of BIT's well-behavedness as formal evidence of soundness. The language covers features of existing template languages and exhibits expressiveness for defining bidirectional and incremental model-to-text transformations in MDD.
		- **COMMENTS**: The paper presents a promising approach, even though, I have several comments and suggestions for improvement. Please consider the following points:
			- The paper lacks an important section, which should discuss existing approaches and highlights their limitations, justifying the need for a new template language. Currently, the paper, after presenting an explanatory bidirectional example, start with presenting BIT with details, without have presented in a convincing manner why it is needed.
			- By following the previous comment I suggest to elaborate a new section containing the following ingredients:
				- Solid process to identify existing bidirectional languages for model-to-text transformations
				- Analysis of the identified approaches and identify their peculiar characteristics/features (even left recursion or efficiency mentioned in the case study sections can be part of the set of features)
				- Devise a comparative table, and corresponding text, to compare the anlyzed approaches and clear discuss if and how the features previously elicited are supported
				- At the end of the section, it will be clear what's the state of the art and what are the unsopported features motivating the need for a new template language
			- Without such a section, currently it is not clear why technologies like QVT (Core and Relation), JTL, AMMA TCS, Epsilon EGL are not considered.
			- Section 5 also requires a major revision. In particular, it needs to be improved by presenting a proper evaluation section, which starts by describing the research questions that the authors want to answer by means of the performed evaluation. The creation of the datasets (including the templates to be developed) should be done with the aim of answering the defined research questions
				- Table 1 should be deeply revised with the aim of making explicit what are the peculiar characteristics of the templates that have been implemented with BIT. Some notion of complexity of peculiarities can be devised in order to categorize templates accordingly and to compare the different approaches with respect to the capabilities of developing them
				- The approaches that are considered in the evaluation section, should be also identified by means of properly define inclusion and exclusion criteria
		- **Minor comments:**
			- Explicitly state whether the proposed approach extends beyond the Ecore ecosystem and if it is generally applicable to various ecosystems.
			- The management of the attribute "no" has been neglected in the example should in Fig. 3 and in Fig. 4 when discussing about parsing and printing
			- Consider moving the full grammar of BIT to an appendix and utilizing section 3 to discuss peculiar aspects of the language through illustrative cases.