Models provide a disciplined representation of information. Model-to-Model (M2M) transformations convert between model structures. When a more readable representation is required, Model-to-Text (M2T) transformations convert a model structure to a concatenation of character sequences. We ignore the obvious conversion dierences and demonstrate that an unmodied M2M tool can be used for M2T. We achieve this with a standard Text model that post-processes the M2M model output to yield formatted text.
reaction was to fall back on orthodoxy; OMG provide distinct specications and anyway M2M and M2T are obviously dierent. However after some reection, it is clear that the "M2" facilities such as metamodels, loading, navigation, expressions, queries and rules are the same for both M2M and M2T. Only the nal "2M" or "2T" need be dierent. Requiring the use of distinct M2M and M2T tools is not justiable.
How might an M2M support text? Only one change and one enhancement appear to be necessary: change: output to a text le rather than model le enhancement: better facilities for creating strings / character sequences 2.1
In MOFM2T, the rules (templates) conspire to concatenate and return Strings.
M2M tools can already do this since the underlying language, typically OCL
[
Typical M2T tools such as Acceleo or Xtend provide a forward escape to embed a control expression within literal text.
The name is "[self.name/]". -- MOFM2T/Acceleo with escaped OCL The name is "this.name". -- Xtend with escaped Java
A backwards escape may dene a multi-line text expression that concatenates with its siblings and may have nested forward escapes. ’The name is "[self.name/]". ’ ’’’The name is "this.name".
’’’ -- MOFM2T -- Xtend
An OCL-based M2M without escapes may only concatenate explicitly. ’The name is "’+ self.name +’".’ -- OCL
OCL provides a fairly modest String library and an overall expression evaluation capability that allows complex String results to be computed. No change is therefore mandated to enable an OCL-based M2M to be used as an M2T although enhanced String capabilities could well be helpful for applications with a high proportion of literal text.
Considering the following example output with a repeated computation: { "firstComputedName", "secondComputedName" }
A for loop facility with optional before/prex, separator and after/sux texts is helpful. The examples below show Acceleo and then Xtend. { [for (p : P | somePs) separator( ’, ’)]"[p.name/]"[/for] } { FOR p : somePs SEPARATOR ’, ’"p.name"ENDFOR }
An OCL-based M2M may use collect() for the content iteration, but the separator splicing is verbose. ’{ ’+ somePs->collect(p | ’"’+ p.name +’"’) ->iterate(s; acc : String = ’’ |
if acc = ’’ then s else acc +’, ’+ s endif ) +’ }’ 3
The need for an XML2XML transformation arises when there is a need to manipulate some aspect of the XMI serialization of a model in a way that is not accessible to a regular M2M. Typically there may be a need to impose some policy on the xmi:ids that are a serialization rather than model artefact. There is no xmi:id within the model technology space and so any solution that tries to expose an xmi:id is messy.
BØzevin [
The proprietary ATL injector and extractor are not necessary when using EMF since the variant loading and saving functionality can be encapsulated by a custom XML Resource allowing it to be used by any M2M tool. We may therefore use the structure shown in Figure 3.
The main diculty in implementing this approach lies in the absence of
a good metamodel for XML. After examining a few candidates, it was clear
that none was suitable as a standard against which users could write their
XML transformations. The SAX parser [
Migrating the functionality from proprietary ATL injector/extractor to EMF Resources enables the XML technology space to be used whenever *.xmlmodel is used as the le extension of an input/output model. No modication to tools is required. The same approach can be used to provide a much simpler and tool-independent solution for using M2M for M2T. This is shown in Figure 4. The M2M transforms to a Text output model which the Text save serializes as a conventional text le.
The main challenge is to design a suitable Text metamodel. 3.3
Language parsers such as lex and yacc [
This conversion sequence is very successful for Text-to-Model conversion but the rules/productions are not appropriate for Model-to-Text conversion since the details of the whitespace formatting are typically discarded once the tokens have been identied. For Model-to-Text purposes, some form of pretty printing is necessary to make the result acceptable to a human reader. We would also like to avoid the language-specic limitations of a typical Text-to-Model grammar.
Traditional M2T tools just concatenate Character Sequences and so we might consider that their text metamodel is just a Sequence of Character. Reifying such a metamodel for M2M usage is easy but the need to assign each character as a distinct model element is pretty unacceptable. Perhaps in QVTo: ... -- ’The name is’ characters += object text::Character { value := ’ ’; }; characters += object text::Character { value := ’"’; }; forEach (c : self.name.characters()) {
characters += object text::Character { value := c; }; } characters += object text::Character { value := ’"’; }; We should therefore look to some form of multi-Character model.
A signicant challenge for practical M2T tools is providing satisfactory indentation and inter-element separation for hierarchical and iterated text structures. The challenge arises because indentation is used within string templates both to indent the output text and to make the control expressions readable.
For Acceleo, the conict between template and control characters can require empirical iteration to get a satisfactory result. The documentation recommends use of a separate pretty formatting pass if non-trivial formatting is needed.
The Xtend UI uses a grey background to distinguish template characters. This is helpful but not always perfect since the grey background is omitted from new-line characters. Empirical programming cannot always solve the problem. 3.4
The M2M transformation language statements provide a readable exposition. The Text Model declarations control pretty printing.
The Text metamodel shown in Figure 5 compromises a tree of StringNode elements organized by the ordered parent/children relationship. Additional attributes control the pretty printing performed by the Text Saver. The result text is formed as the concatenation of a depth-rst traversal of the value of the text property of each StringNode.
The detailed formatting of groups of children is facilitated by a prefix before the rst, a separator between each child and a suffix after the last child. Additionally an endText may follow the children even if there are no children.
The indent species an indentation increment for this node. The cumulative indentation of a node and its parents starts every non-empty line.
An M2M transforms to create the StringNode tree comprising the important text segments and formatting declarations that inuence the nal serialization. No characters are provided that are not directed by the StringNode.
The Text Saver is implemented by a custom EMF TextResource that replaces the conventional XML serialization by the pretty printed text resulting from the depth rst tree traversal and formatting declarations.
A corresponding Text Loader is also implemented, mainly for test purposes.
The serialization during a Text Save is not fully reversible and so the
corresponding replacement functionality when loading is limited to identifying whitespace
indentation hierarchies and punctuation separators for matching indentations.
Any serious Text-to-Model application probably needs a more powerful approach
such as an Xtext parser [
The Text Model has been used in conjunction with Eclipse QVTo to generate C, H, Lex (Flex) and Y (Bison) les from an Ecore le for an auto-generated XMI loader.
No changes were required to Eclipse QVTo and only a couple of minor bug reports were raised. Problems were easily circumvented. Overall there seemed to be fewer problems than when using Acceleo or Xtend. All approaches share the pleasant characteristic of M2T development that problems are clearly visualized in the textual output. Additional debug output can provide helpful insights. Development time was focussed on the correct content of the Flex and Bison declarations to be generated rather than struggling with their formatting.
Execution of the M2M for text is fast. The 2000 lines of the four XMI loader les are generated in less than a second. 4.1
The utility of this approach can be assessed by examining a very simple example that is articially elaborated to demonstrate important facilities. The target output is the textile snippet shown in Figure 6. The snippet comprises a heading, a blank line then a list of separated formatted elements.
The Acceleo solution in Figure 7 formats the heading and blank line as literal text at the start of emitPrecedences2. The [for...]...[/for] construct supports the formatting of p.name using a [.../] escape to access the name. The additional separator argument denes the inter-text separation.
The redundant emitPrecedences1 demonstrates that declarations occur as escapes within the surrounding text literal and the need to re-escape in order to make a nested call.
The Xtend solution in Figure 8 is very similar except for the guillemet rather than square bracket escapes.
The redundant emitPreferences1 demonstrates that declarations occur as functions within an outer control ow allowing a direct call to a nested function. The inner emitPrecedences2 uses the ’’’...’’’ backward escape from the outer control to the inner text template formatting. This allows the inner template to be indented for readability.
The new QVTo and Text Model solution is shown in Figure 9. It is a little more verbose (or a little more modular). The inner formatting is factored out as emitPrecedence3 that constructs a StringNode comprising just the formatted precedence element. Since there is no string template capability, the self.name expression needs no elaboration, but the text needs quoting and concatenation. emitPrecedences2 provides the heading as its text, and iterates emitPrecedences3 to dene the children. The separator and children StringNode elements provide very similar capability to the for construct of Acceleo or Xtend.
The redundant emitPrecedences1 demonstrates use of the init section to
bypass creation of a nested StringNode. The intermediate Text model instances
created by QVTo are shown in Figure 10.
The OMG issued the MOF Model to Text Transformation Language Request For
Proposal (MOFM2T RFP) in April 2007 as a follow on to the MOF 2.0 Query
/ Views / Transformations RFP (QVT RFP) which addressed only
Model-toModel transformation. The MOFM2T RFP [
The nal MOFM2T submission [
In contrast, in this paper we re-use QVTo (or QVTr or ATL or ...) unchanged to support M2T. This was possible with just one day of development for the oneclass metamodel and its associated support.
It might seem that a fully declarative transformation language such as QVTr for M2T could result in the output paragraphs appearing in unpredictable orders? But no, if all collections are ordered, a declarative transformation result should also be ordered; only unordered collections may yield shued results. 5
The http://www.eclipse.org/qvt/2018/TextModel metamodel and its support was made available in June 2018 as part of the Eclipse Photon release once the Eclipse QVTd support is also installed. It may be bundled with ATL and/or QVTo in future releases.
The current support is usable. The text model is powerful, but could be extended. More signicant is the opportunity for syntax sugar to make that power more accessible. 5.1 The inelegance of the splicing at the end of Section 2.2 may be mitigated by adding a splice() iterator to the OCL Standard Library for ordered collections of toString()-able elements. This could support: ’{ ’+ somePs->splice(p; separator= ’,’ | ’"’+ p.name +’"’) +’ }’ 5.2
Line wrapping is not conventionally available for M2T. Separation of information and rendering concerns enables the Text Model saver to respect a prevailing indentation and line-breaking policy and wrap lines accordingly. Figure 5 shows a nonBreakingSpace property that is intended to provide a facility to control automatic wrapping of too-long lines. Long lines are rst broken at spaces or tabs, then non-breaking space characters are replaced by space characters. 5.3
Tools such as Xtext have demonstrated how the addition of model assignment
annotations to an EBNF grammar can synthesize a useful parser/editor rather
than just a partial parser. No equivalent extension is available to add
prettyprinting annotations, rather Xtext supports manual programming of an
independent declarative class. TCS [
In the introduction we identied a need to facilitate text synthesis. The evaluation in Section 4 observed that String Templates are not essential, although they may be useful, particularly for output comprising mostly boilerplate.
A string template expression could be added to OCL, in much the same way as it has been to Xtend, but learning from Xtend, Acceleo and MOFM2T, four escape tokens are needed for the start and end of a forward or backward escape. Acceleo has only 2, Xtend and MOFM2T just 3 which inhibits arbitrary nesting. Again learning from Xtend, guillemets are very readable and so we might use: ocl-expression ’string-template ’ forwards escape within literal text
backwards escape - an ocl-expression
An OCL expression starting or ending with a ’ can be disambiguated with a space. Literal guillemets may be escaped.
’literal-text’
disambiguated ocl expression escaped literal guillemets
These escapes enable the core of our evaluation example from Section 4 to nest an ocl-expression within a string-template within an ocl-expression within a string-template within a QVTo statement. map Pivot::ModelemitPrecedences2() : Text::StringNode { ’ h2(#Precedences). *Precedences* getPrecedences(m)->splice(separator = ’ }
An OCL evaluation of string-templates should compute the appropriate string result. An M2M compilation may recognize that string-templates and splice() are syntax sugar for Text Model capabilities.
Incremental or parallel execution is dicult in an M2M with imperative characteristics such as QVTo, but very practical in a purely declarative language such as QVTr. Therefore if QVTr is used as the M2M, an incremental execution can mark dirty StringNode elements in the tree that can then be selectively reserialized. Unfortunately incremental QVTr execution is not yet available. A parallel execution can distribute parts of the StringNode tree to multiple proocessors and bring the results together at the end. 6
Dening a really simple text model to allow an M2M transformation language to be used for an M2T seems like a rather obvious idea. However string template orthodoxy is so entrenched that this simple tree model seems to have been overlooked. Consequently many tools and researchers use naive Strings and then struggle to recover lost structure.
Ogunyomi [
Figure 11 shows a Feature Model for our use of M2M for M2T in the style
proposed by Rose [
This highlights that the mandatory forwards escaping is missing; we have proposed an OCL extension to remedy this. In other respects, the M2M facilities provide good feature coverage and additional features regarding model output. The external text model provides for extensibility.
Tisi et all [
We have introduced a very simple one-class metamodel that models text as a tree of attributed character sequences.
We have shown that this metamodel separates the content and pretty printing concerns and enables any M2M to be used without modication as an M2T.
We have demonstrated the usability of this approach by using Eclipse QVTo to generate c, h, lex and y les from an Ecore metamodel.
We have outlined minor extensions to OCL to improve OCL-based M2M usability for M2T.
We can therefore argue that this simple approach to M2T is more compliant with the OMG MOFM2T RFP than the MOFM2T specication.