Skip to main content
Jump to: navigation, search

Difference between revisions of "TMF"

(added details about what the TMF textual concrete syntax DSL should support, and about GMF-TMF hybrid editors)
(moved old page to TMF/LongRunPlans, wrote something more overview like)
Line 1: Line 1:
Here we can discuss our proposals and requests for a Textual Modeling Framework.
+
The Textual Modeling Framework (TMF) is an umbrella project under the Eclipse Modeling Project (EMP).
TMF architecture and implementation are defined according to the experience gained in the development of the [http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/xtext_reference.html xText] and [[TCS]] [[GMT]] components.
+
It hosts two different framework for implementation of textual syntax for EMF models (aka Ecore models).
  
==Expected TMF Features==
+
= TCS =
 +
[[TCS]] (Textual Concrete Syntax) comes from GMT.
 +
With TCS one annotates concrete syntax information to existing ecore models.
 +
The editor is not generated but interpreted.
  
This section contains a list of expected features to be supported by TMF:
+
= Xtext =
* A Domain-Specific Language (DSL) for textual concrete syntax definition. The abstract syntax of languages is defined as a metamodel (e.g., in [[EMF]] [[Ecore]], in [[KM3]]). The TMF DSL for textual concrete syntax definition will provide means to specify how each metamodel concept is represented textually, similarly to what [[TCS]] currently does. This DSL should support:
+
[[Xtext]] is a part of the openArchitectureWare framework, but is now developed under modeling.tmf.xtext. It still will be a part of future openArchitectureWare releases.
** Definition of non context-free elements (e.g., symbol table used for cross-references).
+
With Xtext one can also write grammars for existing meta models. In addition it is possible to derive ecore models from grammars, since a grammar contains sufficient information about the structure of parsed models.
** Declarative definition of operators, and automatic generation of specific grammar rules to handle them.
+
Xtext implements EMF's resource API (it is possible to use xtext based syntax transparently through the resource load and save functionality, hence you can use e.g. GMF editors for Xtext based DSLs). Xtext also generates a rich IDE for your language, which can be easily customized via dependency injection.
* Support for definition of TMF textual syntaxes from a grammar. In this case, both a metamodel (abstract syntax), and a TMF textual syntax model (concrete syntax) may be generated from the grammar. This mechanism will enable reuse of existing grammars, as well as accommodate developers with a grammarware background.
+
** TBD: we may not want to force a one way translation from the grammar, but also support grammar-based development (e.g., like in [http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/xtext_reference.html xText]). However, supporting this is likely to be more expensive than requiring a transition to metamodel + TMF textual syntax model.
+
* Parsing and pretty-printing. Using the syntax specification, TMF will provide:
+
** parsing (or injection) to translate textual programs into models (e.g., in EMF).
+
** pretty-printing (or extraction) to translate models into program.
+
* Syntax-aware editors. Using the syntax specification of a given language, TMF will provide a lightweight (e.g., interpretative) language-specific editor with: syntax highlighting, text hovers, hyperlinks, an outline, etc. This editor may integrate with GMF to provide Graphical-Textual hybrid editors. This editor would be similar to:
+
** the current TCS-based Textual Generic Editor (TGE), as illustrated in the screenshots of the [http://www.eclipse.org/gmt/tcs TCS project page], and on the image [[Image:LOTOS-TGE.png|thumb|TGE screenshot]] at the right of this paragraph.
+
** the [http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/xtext_tutorial.html#xtext_tutorial_fill_model xText editor].
+
* Support for constraints checking in the TMF language-specific editor.
+
* Support for language extension. Extending a language will consist of:
+
** extending its metamodel (i.e., abstract syntax), which is going to be based on mechanisms provided by metametamodels (e.g., [[EMF]] [[Ecore]] inter-metamodel references, [[KM3]] metamodel extension).
+
** extending its concrete syntax, which is going to be based on specific support for extension in the TMF textual concrete syntax DSL.
+
* A library of TMF-defined languages. This library will illustrate TMF usage, and may serve as a collection of examples, but also as a starting point (e.g., by extending the languages it provides). An example of such a library is the [[TCS/Zoo|TCS zoo]].
+
  
==Flexible Implementation Requirements==
+
= Future Plans =
 
+
It is intended that at some point there will be only one framework instead of two.
This section contains a list of requirements regarding the implementation of TMF, and its (relative) independence with respect to specific tools:
+
Requirements and thoughts can be discussed [[TMF/LongRunPlans|here]]
* Support for several parsing back-ends. Instead of targeting a single parser generator, TMF will have a flexible architecture (see Figure 1) enabling support for parser generators like: [http://www.antlr.org/ ANTLR], [http://sourceforge.net/projects/lpg/ LPG]. This can be achieved using a mechanism such as the [http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt/org.eclipse.gmt.tcs/plugins/org.eclipse.gmt.tcs.injector/src/org/eclipse/gmt/tcs/injector/wrappers/ParserWrapper.java?view=markup ParserWrapper] class of [[TCS]].
+
* Support for several editing back-ends. The TMF architecture will accommodate several kinds of language-specific editors: [http://www.eclipse.org/proposals/imp/ IMP] (formerly known as SAFARI), the lightweight TMF-specific editors, etc.
+
* Support for several kinds of constraints checking engines.
+
* Support for several modeling framework. Although EMF is the primary modeling framework on which TMF will be based, some features (such as parsing, and pretty printing) should work with other frameworks (including pure Java ASTs?).
+
** API-independence may be achieved using a mechanism such as the [http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt/org.eclipse.gmt.tcs/plugins/org.eclipse.gmt.tcs.injector/src/org/eclipse/gmt/tcs/injector/ModelHandler.java?view=markup ModelHandler] interface of [[TCS]].
+
** Metametamodel-independence may be achieved using a metametamodel pivot such as the [[KM3|Kernel MetaMetaModel (KM3)]].
+
 
+
 
+
[[Image:TMF_ArchitectureV1.png|frame|center|Figure 1. Architecture of the TMF grammar generator ([[Media:TMF_ArchitectureV1.zip|zipped Visio source]])]]
+
 
+
 
+
==Other Considerations==
+
 
+
This section contains a list of requirements that do not fit in the previous sections:
+
* A model-based implementation. As far as possible, TMF implementation will use Model Engineering techniques: model-to-model ([M2M]) transformations to create grammars or editor configurations from TMF definitions (i.e., similarly to what TCS and TGE [http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt/org.eclipse.gmt.tcs/dsls/TCS/Compiler/TCS2ANTLR.atl?view=markup currently do]), [[Model to Text (M2T)]] for Java code or documentation generation, etc.
+
** This requirement will show our confidence in Model Engineering techniques.
+
** To achieve a model-based implementation, the syntax of the TMF textual concrete syntax definition TCS will have to be bootstrapped. In a first step, it will be defined using either [[TCS]] or xText.
+
 
+
 
+
[[Category:Modeling]]
+

Revision as of 10:10, 11 November 2008

The Textual Modeling Framework (TMF) is an umbrella project under the Eclipse Modeling Project (EMP). It hosts two different framework for implementation of textual syntax for EMF models (aka Ecore models).

TCS

TCS (Textual Concrete Syntax) comes from GMT. With TCS one annotates concrete syntax information to existing ecore models. The editor is not generated but interpreted.

Xtext

Xtext is a part of the openArchitectureWare framework, but is now developed under modeling.tmf.xtext. It still will be a part of future openArchitectureWare releases. With Xtext one can also write grammars for existing meta models. In addition it is possible to derive ecore models from grammars, since a grammar contains sufficient information about the structure of parsed models. Xtext implements EMF's resource API (it is possible to use xtext based syntax transparently through the resource load and save functionality, hence you can use e.g. GMF editors for Xtext based DSLs). Xtext also generates a rich IDE for your language, which can be easily customized via dependency injection.

Future Plans

It is intended that at some point there will be only one framework instead of two. Requirements and thoughts can be discussed here

Back to the top