Merge "Bug 549183: [Model2Doc] Tree table import doesn't work when there is only one column"
diff --git a/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-devDoc.mediawiki b/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-devDoc.mediawiki
index eebda1a..81c6eec 100755
--- a/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-devDoc.mediawiki
+++ b/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-devDoc.mediawiki
@@ -7,86 +7,88 @@
 **'''plugins/dev''': contains developer tools for Papyrus-Model2Doc
 **'''doc''': the documentation plugin
 **'''emf''': plugins created to work with EMF metamodels
-**'''gmf''': extension for GMF metamodel
+**'''gmf''': extension for the GMF metamodel
 **'''integration''': plugins managing the integration of Model2Doc into Papyrus
-**'''odt''': required plugins to generate odt file
-**'''uml''': extension for UML metamodel
+**'''odt''': required plugins to generate the odt file
+**'''uml''': extension for the UML metamodel
 
 
 =DocumentStructureTemplate metamodel=
-This metamodel allows to define how to cross a model, which information extract from him and how to include them in the final Document. 
+This metamodel defines how to parse a model, what information to extract from it and how to include them in the final Document. 
 This metamodel is provided by the plugin '''org.eclipse.papyrus.model2doc.emf.documentstructuretemplate'''.
 
 [[Image:images/devDoc/devDoc_001_Document_Structure_Template.png]]
-This snapshot shows the basis elements of this metamodel.
+This snapshot shows the basic elements of this metamodel.
 *'''DocumentTemplate''': the interface to realize to provide a new kind of DocumentTemplate.
-*'''TextDocumentTemplate''': this class allows to define a DocumentTemplate for text file. This kind of template is composed of '''DocumentPart'''
+*'''TextDocumentTemplate''': this class is used to define a DocumentTemplate for text file. This kind of template is composed of '''DocumentPart'''
 *'''DocumentPart''': it can be a '''TableOfContents''' or a '''Body'''
-*'''Table Of Contents''': allow to define that the generated document will have a table of contents
+*'''Table Of Contents''': defines that the generated document will contain a table of contents
 *'''Body''': this element is composed of '''IBodyPartTemplate'''
 *'''IBodyPartTemplate''': 
-**The construction of this element is very interesting, because we use a 2-level construction ('''IBodyPartTemplate''' and '''ISubBodyPartTemplate''' to allow to distinguish 2 kind of elements (below in the documentation, navigation between '''EReferencePartTemplate''' and '''EClassPartTemplate''', so we will be able to navigate alternatively between '''EReference''' and '''EClass''';
+**The construction of this element is very interesting, because we use a 2-level construction ('''IBodyPartTemplate''' and '''ISubBodyPartTemplate''' to distinguish 2 kind of elements (below in the documentation, '''EReferencePartTemplate''' and '''EClassPartTemplate''', so we will be able to navigate alternatively between '''EReference''' and '''EClass''';
 **In addition, we define composed objects and leaf object.
-**'''IComposedBodyPartTemplate''' and '''IComposedsubBodyPartTemplate''' will be extend to create elements which can have children. Typically, a navigation from an EObject to an EReference which itself refers to others EObject. 
-**'''ILeafBodyPartTemplate''' and '''ILeafSubBodyPartTemplate''' will be extend to create elements with not children, typically to create a View in the document. 
+**'''IComposedBodyPartTemplate''' and '''IComposedsubBodyPartTemplate''' will be extend to create elements that can have children. Typically, a navigation from an EObject to an EReference which itself refers to other EObject. 
+**'''ILeafBodyPartTemplate''' and '''ILeafSubBodyPartTemplate''' will be extended to create elements with no children, typically to create a View in the document. 
 
 
-On the next snapshot we show the construction of the '''EReferencePartTemplate''' and '''EClassPartTemplate'''. As indicated upper, this construction allows to navigate alternatively between an object and a property of this object.
+On the next snapshot we show the construction of the '''EReferencePartTemplate''' and '''EClassPartTemplate'''. As indicated previously, this construction allows the navigation between an object and a property of this object recursively.
 [[Image:images/devDoc/devDoc-002_EMF-DiagramNavigation.png]]
 
 
 
 =How to provide new part template for the Body of a TextDocumentTemplate?=
-Here we can't explain all EMF tricks, configuration and so on, so we will give you only the most important steps. 
+We can't explain all the EMF tricks employed, configuration and so on, but we will detail the most important ones. 
 
 #You must have installed the Papyrus Toolsmiths plugins
 #You must have installed the feature '''UML2 SDK Extender''' to be able to generate a EMF model from a UML one.
 
 ==Create a new PartTemplate in a UML model==
 #There is 2 choices about the way to proceed
-##You can edit one of the DocumentStructureTemplate metamodel provided by Papyrus-Model2Doc and contribute it to the Eclipse Project
-##You create a new metamodel (and share it with Papyrus-Model2Doc project or not)
-#You need to define what you want to do:
-##a new navigation looking like an EMF EStructuralFeature? 
-###with possible sub-elements -> implements the interface '''IComposedBodyPartTemplate'''
-###with no sub-element -> implements the interface '''ILeafBodyPartTemplate'''
-##a new navigation looking like an EMF EClass?
-###with possible sub-elements -> implements the interface '''IComposedSubBodyPartTemplate'''
-###with no sub-element -> implements the interface '''ILeafSubBodyPartTemplate'''
+##You can either edit one of the DocumentStructureTemplate metamodel provided by Papyrus-Model2Doc and contribute it to the Eclipse Project
+##Or you can create a new metamodel (and share it with Papyrus-Model2Doc project or not)
+
+#You then need to define what you want to do:
+##A new navigation looking like an EMF EStructuralFeature? 
+###With possible sub-elements -> implements the interface '''IComposedBodyPartTemplate'''
+###With no sub-element -> implements the interface '''ILeafBodyPartTemplate'''
+##A new navigation looking like an EMF EClass?
+###With possible sub-elements -> implements the interface '''IComposedSubBodyPartTemplate'''
+###With no sub-element -> implements the interface '''ILeafSubBodyPartTemplate'''
 
 ''N.B.: The UML element to implement a UML Interface in a UML model is the element'' '''''InterfaceRealization'''''.
-We advise against to extends others elements of this metamodel. 
+We advise against extending other elements of this metamodel. 
   
-In the general way, to provide a new view, we consider that a such element as no children and we use a feature to calculate the contents of the view. 
+In general, to provide a new view, we consider that such an element has no children and we use a feature to calculate the contents of the view. 
 That's why '''TreeListView''' and '''EReferenceTableView''' implements '''ILeafBodyPartTemplate'''.
 
-To illustrate this description, we advice you to look at the '''UMLDocumentStructureTemplate''' metamodel which extends the base metamodel '''DocumentStructureTemplate''' to provide support for '''UML Stereotype''' and '''Stereotype's properties'''. In this metamodel, '''StereotypePartTemplate''' is built to be at the same level than '''EClassPartTemplate''' and '''StereotypePropertyReferencePartTemplate''' to be at the same level than '''EReferencePartTemplate'''.
-In addition, this metamodel provides the object '''CommentAsParagraph''' considered as a view and described as an '''ILeafBodyPartTemplate''', to be at the same level than '''EReferencePartTemplate'''.
+To illustrate this description, we advise you to look at the '''UMLDocumentStructureTemplate''' metamodel which extends the base '''DocumentStructureTemplate''' metamodel to provide support for '''UML Stereotype''' and '''Stereotype's properties'''. In this metamodel, '''StereotypePartTemplate''' is defined to be at the same level than '''EClassPartTemplate''' and '''StereotypePropertyReferencePartTemplate''' to be at the same level than '''EReferencePartTemplate'''.
+In addition, this metamodel provides the '''CommentAsParagraph''' object, considered as a view and described as a '''ILeafBodyPartTemplate''', which is at the same level than the '''EReferencePartTemplate'''.
 
 ==Generate==
 Once you created your new element, you need to generate it.
-#Open the existing '''genmodel''' file, then ''Right-Click->Reload'' (or create a new one, in case of new uml model).
-#On the root of this file, ''Right-Click->Generate Model'', then ''Generate Edit'' (and ''Generate Editor, only if you work on the metamodel '''DocumentStructureTemplate'''.
+#Just open the existing '''genmodel''' file, then ''Right-Click->Reload'' (or create a new one, in case of new uml model).
+#On the root of this file, ''Right-Click->Generate Model'', then ''Generate Edit'' (you can ''Generate Editor'', but this should only be necessary if you need to work on the '''DocumentStructureTemplate''' metamodel).
 
 ''N.B. if you add a property to an interface and if this interface is implemented in sub-metamodel, you will need to regenerate all these sub-metamodels too!!!''
 
 ==Implementation of IBodyPartTemplate#buildPartTemplateTitle==
-Due to the root interface '''IBodyPartTemplate''' of these element, you must provide an implementation of the method '''buildPartTemplateTitle'''. There is 2 ways for that: 
-#solution1: provide a factory override for your metamodel, then provides a custom implementation of the generated class implementing this method (see extension point '''"org.eclipse.emf.ecore.factory_override"''').
+Due to the root interface '''IBodyPartTemplate''' of these element, you must provide an implementation of the method '''buildPartTemplateTitle'''. There is 2 ways to do this: 
+#solution1: 
+##Provide a factory override for your metamodel, then provides a custom implementation of the generated class implementing this method (see the '''"org.eclipse.emf.ecore.factory_override"''' extension point).
 #solution2:
-##in the UML model, create a new operation '''buildPartTemplateTitle''' in your element, then in the ''Advanced'' tab of the ''Property View'', edit the field '''redefined operations''' referencing the operation ''''''buildPartTemplateTitle''' of the parent interface. 
-##in your UML model, create an '''EAnnotation''' as child of your element (from the Papyrus ''ModelExplorer'' view, ''Right-Click->Create EAnnotation'';
-###in the ''Property View'', set '''http://www.eclipse.org/emf/2002/GenModel''' as ''source''.
-##always from the ''Model Explorer'' view, create a '''Details Entry''' as child of the '''EAnnotation''';
-###in the ''Property View'', set '''body''' as key and the java body of the method in the '''value''' field.
-##return into the '''genmodel''' file, reload model and regenerate all as done previously. 
+##Create a new '''buildPartTemplateTitle''' operation in your element, in the UML model, then, in the ''Advanced'' tab of the ''Property View'', edit the field '''redefined operations''' referencing the operation ''''''buildPartTemplateTitle''' of the parent interface. 
+##In your UML model, create an '''EAnnotation''' as child of your element (from the Papyrus ''ModelExplorer'' view, ''Right-Click->Create EAnnotation'';
+###In the ''Property View'', set '''http://www.eclipse.org/emf/2002/GenModel''' as ''source''.
+##From the ''Model Explorer'' view, create a '''Details Entry''' as child of the '''EAnnotation''';
+###In the ''Property View'', set '''body''' as key and the java body of the method in the '''value''' field.
+##Finally, return into the '''genmodel''' file, reload model and regenerate it all as previously explained. 
 
-You can also provide a nice icon in the edit plugin for your created element. To provide an icon, erase the icon provided by default by the generation. 
+You can also provide a nicer icon in the edit plugin for your created element, just replace the default icon provided by the generation. 
 
 At this step, the new element will be available in the Creation menu of the DocumentTemplate editor. 
 
 ==How to contribute to the EMF property view?==
-The default property view is already managed by the EMF-Framework. If you need to change the default edition of a property, you need to create an '''EAnnotation''' with a '''Details Entry''' in your UML model, as child of the property for which you need to provide a custom editor.
+The default property view is already managed by the EMF-Framework. If you need to change the default edition of a property, you need to create an '''EAnnotation''' with a '''Details Entry''' in your UML model as child of the property for which you need to provide a custom editor.
 *'''EAnnotation#source:'''http://www.eclipse.org/emf/2002/GenModel
 *'''DetailsEntry#key:'''propertyEditorFactory
 *'''DetailsEntry#value:''': a unique string, like this one for example:''editor://umldocumentstructuretemplate/StereotypePropertyTemplate/propertyName/''
@@ -95,10 +97,10 @@
 
 ==How to contribute to the EMF property view embedded in Papyrus (Advanced Tab)?==
 This code should be done in a plugin called ''org.eclipse.papyrus.integration.xxx'' to respect the naming convention. 
-We advice you to manage the EMF property view, before embedding it in Papyrus (because there is common code between them). 
+We advise you to manage the EMF property view, before embedding it in Papyrus (because there is shared code between them). 
 ===In case of new DocumentStructureTemplate metamodel===
-*A example, you can look at the plugin <code>org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties</code>
-*Contribute to the extension point <code>org.eclipse.ui.views.properties.tabbed.propertySections</code>, you should get something like this:
+*As an example, you can look at the plugin <code>org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties</code>
+*To contribute to the extension point <code>org.eclipse.ui.views.properties.tabbed.propertySections</code>, you should get something like this:
   
    <extension
          point="org.eclipse.ui.views.properties.tabbed.propertySections">
@@ -116,16 +118,16 @@
       </propertySections>
    </extension>
 
-*'''class''': we advice you to extends <code>org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties.sections.AbstractEObjectAdvancedPropertySection</code>. This class will provide a <code>org.eclipse.emf.edit.ui.provider.PropertySource</code>, this <code>PropertySource</code> will provide custom <code>org.eclipse.ui.views.properties.IPropertyDescriptor</code>.
+*'''class''': we advise you to extend <code>org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties.sections.AbstractEObjectAdvancedPropertySection</code>. This class will provide a <code>org.eclipse.emf.edit.ui.provider.PropertySource</code>, this <code>PropertySource</code> will provide a custom <code>org.eclipse.ui.views.properties.IPropertyDescriptor</code>.
 *'''filter''': a class implementing <code>org.eclipse.jface.viewers.IFilter</code> 
 
 ===In case of new property in an existing metamodel===
 You just need to manage your new feature in the method <code>PropertySource.createPropertyDescriptor(IItemPropertyDescriptor)</code> of the existing <code>PropertySource</code>
 
 ==How to contribute a new mapper?==
-The mappers are in charge to read the model and the DocumentTemplate to create the DocumentStructure. 
-As example, you can look the plugin <code>org.eclipse.papyrus.model2doc.emf.template2structure</code>.
+The mappers are in charge of reading the model and the DocumentTemplate to create the DocumentStructure. 
+As an example, you can look the plugin <code>org.eclipse.papyrus.model2doc.emf.template2structure</code>.
 *Create a new class inheriting from <code>org.eclipse.papyrus.model2doc.emf.template2structure.mapping.AbstractTemplateToStructureMapper<INPUT></code>
 *Register it in the plugin.xml with the extension point <code>org.eclipse.papyrus.model2doc.emf.template2structure.structuregenerator</code>
-**the ''id'' field is the id of the generator you contribute. The generator's id provided by Papyrus-Model2Doc is ''TextDocumentStructureGenerator.default''
+**the ''id'' field is the id of the generator you wish to contribute. The generator's id provided by Papyrus-Model2Doc is ''TextDocumentStructureGenerator.default''
  
\ No newline at end of file
diff --git a/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-papyrusDevDoc.mediawiki b/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-papyrusDevDoc.mediawiki
index 4b3a09e..742fe7b 100755
--- a/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-papyrusDevDoc.mediawiki
+++ b/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-papyrusDevDoc.mediawiki
@@ -1,21 +1,21 @@
 =Introduction=
-This chapter describes the Papyrus integration for Papyrus-Model2Doc.
+This chapter describes the Papyrus integration of Papyrus-Model2Doc.
 
 ==How to register a DocumentTemplatePrototype into an existing Architecture file?==
-For this step, you can check the plugin <code>org.eclipse.papyrus.model2doc.integration.uml.architecture</code> which is used as example here.
-This plugin provides a generic DocumentTemplate for UML model.
+For this step, you can check the plugin <code>org.eclipse.papyrus.model2doc.integration.uml.architecture</code> which is used as an example here.
+This plugin provides a generic DocumentTemplate for a UML model.
 
-The next explanation deals about the contribution to existing Architecture Framework/Viewpoint defined by Papyrus UML. It is not necessary to define all contribution into a unique ''.architecture'' file, as you will see here. 
+The following points deal about the contribution to existing Architecture Frameworks/Viewpoints defined by Papyrus UML. It is not necessary to define all contribution into a unique ''.architecture'' file, as you will see here. 
 
 ====1. Set domain====
 [[Image:images/papyrusDevDoc/architecture/Architecture_001_SetDomain.png]]
 
 ====2. Set language====
-Select domain element, open menu context and select '''New Child > Description Language'''.
+Select the domain element, open the contextual menu and select '''New Child > Description Language'''.
 
 [[Image:images/papyrusDevDoc/architecture/Architecture_002_SetLanguage.png]]
 ====3. Set viewpoints====
-Select language element, open menu context and select '''New Child > Viewpoint'''.
+Select the language element, open the contextual menu and select '''New Child > Viewpoint'''.
 
 =====3.1 Add Software Analysis viewpoint=====
 [[Image:images/papyrusDevDoc/architecture/Architecture_003_SetSotfwareAnalysisViewpoint.png]]
@@ -24,14 +24,14 @@
 [[Image:images/papyrusDevDoc/architecture/Architecture_004_SetSotfwareDesignViewpoint.png]] 
 
 ====4. Reference your DocumentTemplatePrototype====
-Select language element, open menu context and select '''New Child > Papyrus Document Prototype'''.
+Select the language element, open the contextual menu and select '''New Child > Papyrus Document Prototype'''.
 =====4.1 Define DocumentPrototype Representation=====
 [[Image:images/papyrusDevDoc/architecture/Architecture_005_SetPapyrusDocumentPrototype.png]] 
 
 '''Notes:'''
 * load your pdst file containing the DocumentTemplatePrototype
 ** reference it in the field ''Misc->Document Template Prototype''
-* in the field ''Implementation Id'', set the same value than the in the ''type'' field of your DocumentTemplatePrototype.
+* in the field ''Implementation Id'', set the same value as the in the ''type'' field of your DocumentTemplatePrototype.
 
 =====4.2 Define Root=====
 [[Image:images/papyrusDevDoc/architecture/Architecture_006_DefineRoot.png]] 
@@ -45,17 +45,17 @@
 
 
 ==Result==
-Select model element (model or package), open menu context and select '''New Document Template > Generic Text Document'''.
+Select the model element (model or package), open the contextual menu and select '''New Document Template > Generic Text Document'''.
 
 [[Image:images/papyrusDevDoc/architecture/Architecture_009_ResultInModelExplorer.png]] 
 
 
 =How to contribute to the EMF property view embedded in Papyrus (Advanced Tab)?=
 This code should be done in a plugin called ''org.eclipse.papyrus.integration.xxx'' to respect the naming convention. 
-We advice you to manage the EMF property view, before embedding it in Papyrus (because there is common code between them). 
+We advise you to manage the EMF property view, before embedding it in Papyrus (because there is shared code between them). 
 ===In case of new DocumentStructureTemplate metamodel===
-#A example, you can look at the plugin <code>org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties</code>
-#Contribute to the extension point <code>org.eclipse.ui.views.properties.tabbed.propertySections</code>, you should get something like this:<code>
+#As an example, you can look at the plugin <code>org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties</code>
+#Contribute to the extension point <code>org.eclipse.ui.views.properties.tabbed.propertySections</code> and you should get something like this:<code>
    <extension
          point="org.eclipse.ui.views.properties.tabbed.propertySections">
       <propertySections
@@ -72,7 +72,7 @@
       </propertySections>
    </extension>
 </code>
-#'''class''': we advice you to extends <code>org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties.sections.AbstractEObjectAdvancedPropertySection</code>. This class will provide a <code>org.eclipse.emf.edit.ui.provider.PropertySource</code>, this <code>PropertySource</code> will provide custom <code>org.eclipse.ui.views.properties.IPropertyDescriptor</code>.
+#'''class''': we advise you to extends <code>org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties.sections.AbstractEObjectAdvancedPropertySection</code>. This class will provide a <code>org.eclipse.emf.edit.ui.provider.PropertySource</code>, this <code>PropertySource</code> will provide a custom <code>org.eclipse.ui.views.properties.IPropertyDescriptor</code>.
 #'''filter''': a class implementing <code>org.eclipse.jface.viewers.IFilter</code> 
 
 ===In case of new property in an existing metamodel===
diff --git a/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-papyrusUserDoc.mediawiki b/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-papyrusUserDoc.mediawiki
index e65f84a..a6275a9 100755
--- a/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-papyrusUserDoc.mediawiki
+++ b/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-papyrusUserDoc.mediawiki
@@ -1,11 +1,12 @@
 =Papyrus-Model2Doc Integration Introduction=
-This part of the documentation deals with features only accessible from the integration to Papyrus, so main part of the Documentation is in the previous chapter '''User Documentation'''
+This part of the documentation deals with features provided by the integration to Papyrus. The main part of the Documentation is in the previous chapter '''User Documentation'''
 
 For a better experience, you should activate the Papyrus Perspective before reading this documentation.
+
 =How to create a new DocumentTemplate in my UML model?=
-Once a UML model created, go into the ''Model Explorer'', select a UML element from which starting the document, then ''Right-Click''->''New Document Template''->''Generic Text Document''.
+Once a UML model is created, go into the ''Model Explorer'', select a UML element from which to start the document, then ''Right-Click''->''New Document Template''->''Generic Text Document''.
 [[Image:images/papyrusUserDoc/PapyrusUserDoc_002_CreateNewDocumentTemplate.png]]
-A tree editor opens in Papyrus. This editor allows you to describe how to traverse your model from the selected element to generate your documentation.
+A tree editor opens in Papyrus. This editor allows you to describe how to parse your model from the selected element to generate your documentation.
 
 [[Image:images/papyrusUserDoc/PapyrusUserDoc_003_DocumentTemplateEditor.png]]
 
@@ -15,6 +16,6 @@
 The created DocumentTemplates are displayed in the ModelExplorer as children of the element referenced as '''Graphical Context'''.
 The EMF-Facet allowing to display them is '''Document Template'''. This customization is loaded by default.
 
-Open ''Model Explorer'' and load ''PapyrusDocument'' customization:
+Open the ''Model Explorer'' view and load the ''PapyrusDocument'' customization:
 
 [[Image:images/papyrusUserDoc/PapyrusUserDoc_001_Load_Customization.png]]
\ No newline at end of file
diff --git a/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-userDoc.mediawiki b/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-userDoc.mediawiki
index d3120f4..a557521 100755
--- a/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-userDoc.mediawiki
+++ b/plugins/doc/org.eclipse.papyrus.model2doc.doc/src/site/mediawiki/model2doc-userDoc.mediawiki
@@ -1,5 +1,5 @@
 =Introduction=
-Papyrus-Model2Doc is an EMF-based document generator for EMF models. To enhance the user experience compared to existing document generation frameworks, the proposed approach is fully model-based while separating the concerns of (1) how the source model is visited, and (2) what is the content of the generated document. Two EMF models are used to provide the description of these two concerns. A documentation-oriented metamodel allows the document-generator specifier to choose what to generate (titles, tables, lists, images for GMF Diagram, insertion of preexisting file...). The generation is done in two steps. The first one create a EMF Tree View of the structure of the final document and the second one, is the generation in the expected document format (currently this generator only target the LibreOffice format (odt file), but other output format can easily be developed). 
+Papyrus-Model2Doc is an EMF-based document generator for EMF models. To enhance the user experience compared to existing document generation frameworks, the proposed approach is fully model-based while separating the concerns of (1) how the source model is visited, and (2) what the content of the generated document is. Two EMF models are used to provide the description of these two concerns. A documentation-oriented metamodel allows the document-generator specifier to choose what to generate (titles, tables, lists, images for GMF Diagram, insertion of preexisting file...). The generation is done in two steps. The first one creates an EMF Tree View of the structure of the final document and the second one, is the generation in the expected document format (currently this generator only target the LibreOffice format (odt file), but other output format can easily be developed). 
 
 [[Image:images/userDoc/userDoc_001_DocumentGenerationProcess.png]]
 
@@ -14,12 +14,12 @@
 You will get all these parts if you installed all Model2Doc features.
 
 =Model2Doc installation=
-<span style="font-size:150%; line-height: 1.31em;">Firstly, you need install LibreOffice SDK 6.0 (or upper) on your computer.</span>
+<span style="font-size:150%; line-height: 1.31em;">First and foremost, you will need install LibreOffice SDK 6.0 (or upper) on your computer.</span>
 
-The update site for the nightly build is [https://hudson.eclipse.org/papyrus/job/Papyrus-Model2Doc/lastSuccessfulBuild/artifact/repository/].
+The update site for Model2Doc's nightly build is [https://hudson.eclipse.org/papyrus/job/Papyrus-Model2Doc/lastSuccessfulBuild/artifact/repository/].
 
-The update site provides these features:
-*'''Papyrus-Model2Doc''': the required plugins to generate a document from a EMF model. Papyrus won't be installed excepted some required plugins like Papyrus Expressions Framework.
+The update site provides the following features:
+*'''Papyrus-Model2Doc''': the required plugins to generate a document from a EMF model. Papyrus won't be installed except some required plugins like the Papyrus Expressions Framework.
 *'''Papyrus-Model2Doc Developper Tools''': some additional toolings for Model2Doc developpers (see developers documentation for further information)
 *'''Papyrus-Model2Doc GMF Support''': provides elements to integrate GMF Diagram as images in your document
 *'''Papyrus-Model2Doc Papyrus Integration''':
@@ -32,9 +32,9 @@
 =DocumentStructureTemplate metamodel elements' description=
 In the document template file:
 *you can create new element by ''Right-Click''->''New Child''
-*you can edit there properties in the property view (''Right-Click''->''Show Property View''.
+*you can edit their properties in the property view (''Right-Click''->''Show Property View''.
 
-*'''TextDocumentTemplate''': The root of the the DocumentTemplate. This element provides these fields:
+*'''TextDocumentTemplate''': The root of the DocumentTemplate. This element provides these fields:
 **'''Description''': a description of the current DocumentTemplate. This field is not used by the generation. 
 **'''Document Template Prototype''': reference the prototype used to create this DocumentStructure
 **'''Graphical Context''': reference the model element under which the DocumentTemplate will be displayed (mainly for Papyrus ModselExplorer integration)
@@ -43,14 +43,14 @@
 **'''Semantic Context''': the model element from which the documentation process will start
 
 Children of the '''TextDocumentTemplate''':
-*'''DocumentStructureGeneratorConfiguration''': allows to configure the generation process. This element provides these fields:
+*'''DocumentStructureGeneratorConfiguration''': enables the configuration of the generation process. This element provides these fields:
 **'''DocumentFolder''':the folder where the generated document will be stored. Supported paths are:
 ***''platform:/resource/aPluginName/aFolderName/...'' : the folder in an Eclipse project of the workspace
 ***''folder1/folder2/...'': interpreted as ''platform:/resource/currentPluginName/folder1/folder2/...'' : folders owned by the current Eclipse project
-**'''DocumentGeneratorId''':the id of the generator to used to transform the DocumentStructure file into the final document.
+**'''DocumentGeneratorId''':the id of the generator used to transform the DocumentStructure file into the final document.
 ***We provide the odt generator, its id is ''org.eclipse.papyrus.model2doc.document.generator.odt''
 **'''DocumentName''': The name of the generated document file
-**'''ImageFolder''': the folder where we store the generated image. Supported path are
+**'''ImageFolder''': the folder where the generated image is stored. Supported path are
 ***''platform:/resource/aPluginName/aFolderName/...'' : the folder in an Eclipse project of the workspace
 ***''folder1/folder2/...'': interpreted as ''platform:/resource/currentPluginName/folder1/folder2/...'' : folders owned by the current Eclipse project
 **'''SaveDocumentStructure''':a boolean value indicating if the generated DocumentStructure must be kept at the end of the process
@@ -60,35 +60,36 @@
 ***''folder1/folder2/...'': interpreted as ''platform:/resource/currentPluginName/folder1/folder2/...'' : folders owned by the current Eclipse project
 **'''StructureGeneratorId''':the id of the generator used to transform the DocumentTemplate into a DocumentStructure
 ***The id of the provided generator is ''TextDocumentStructureGenerator.default''
-**'''TemplateFile''': this file is used to initialize the generated document. It can contains style definition, headers, ... For LibreOffice generation, it is an ''ott'' file. This file can be used to define the cover page too. The supported path are:
+**'''TemplateFile''': this file is used to initialize the generated document. It can contains the style definitions, headers, ... For LibreOffice generation, it is an ''ott'' file. This file can be used to define the cover page too. The supported path are:
 ***''platform:/resource/aPluginName/aFolderName/myTemplatefile'' : the template is located in an Eclipse project of the workspace
 ***''folder1/folder2/myTemplateFile'': interpreted as ''platform:/resource/currentPluginName/folder1/folder2/myTemplateFile'' : template owned by the current Eclipse project
 ***''platform:/plugin/aPluginName/aFolderName/myTemplatefile'' : the template is located in an installed Eclipse plugin
 ***''OS file system ''C:\aFolder\myTemplatefile'': the template is located somewhere in the file sytem
-*'''TableOfContents''': this element allows to declare you want a TableOfContents
+*'''TableOfContents''': this element is used to declare that you want a TableOfContents
 **'''TocTitle''': the title to use for the TableOfContents. If nothing is defined, the table of contents will be name ''Table Of Contents'' in the generated file
-*'''Body''': The children of this element allows to define the contents of the document
-*'''Author''': allows to define authors of the document
+*'''Body''': The children of this element allows the definition of the document's content
+*'''Author''': allows to define the authors of the document
 
 ===Body's description===
-This element is the most important of the '''TextDocumentTemplate''' file. It defines the contents of the generated document. Here we declare how to process to cross the model. Basically, we start referencing an EReference (first level) to use to get values from the semantic context of the document, then an EClass (second level), then an EReference again to get the value of the found elements at the previous level, and again EClass, ... Of course others elements are possible, but the goal is to declare a navigation alternating EReference and EClass.
+This element is the most important part of the '''TextDocumentTemplate''' file. It defines the contents of the generated document. Here we declare how to parse the model. Basically, we start referencing an EReference (first level) used to get the values from the semantic context of the document, then an EClass (second level), then an EReference again to get the value of the found elements at the previous level, and again EClass, ... Of course others elements are possible, but the goal is to declare a navigation alternating between EReference and EClass.
 
-The generation process will start taking values (for referenced features) on the '''semanticContext''' of the '''DocumentTemplate'''. These values will be filtered with the second levels of DocumentTemplate's elements, then we take these elements and use them as input of the third level which references features too, and we continue crossing the model and the DocumentTemplate. 
+The generation process will start by taking the semanticContext of the '''DocumentTemplate''' and asking it the values of the property represented by the '''EReference''' declared in the '''DocumentTemplate'''.
+These values will be consummed by the second level of '''DocumentTemplate''' elements to extract relevant ones. Then we take these results and use them as input of the third level which references features too. After this the process will continue by parsing the model using the DocumentTemplate. 
 
 
 #First level element
 ##''pure EMF''
-###'''EReferencePartTemplate''': to choose a EReference to use. This element can have children
+###'''EReferencePartTemplate''': to choose which EReference to use. This element can have children
 ###'''EReferenceTableView''': to create a table from a reference value (detail further in the documentation).
 ###'''TreeListView''': to create a list from EStructuralFeature values (detail further in the documentation).
-###'''InsertFileTemplate''': allow to declare a path to a file to integrate into the generated document. It won't be a reference, but a copy of its contents into the generated file.
+###'''InsertFileTemplate''': to declare a path to a file to integrate into the generated document. It won't be a reference, but a copy of its contents into the generated file.
 ##''GMF''
-###'''GMFDiagramView''': allow to define the type of the Diagram owned by the context element to include as image
+###'''GMFDiagramView''': to define the type of the Diagram owned by the context element to include as image
 ##''Papyrus GMF''
 ###'''PapyrusGMFDiagramView''': used to import a Papyrus diagram as image. It allows to define:
 ###*the type of the Diagram to include as image
 ###*the kindId of the Diagram to include as image (Papyrus Architecture Framework information)
-###*a context filtering rule to find diagram by semanticContext (called Root element in the Papyrus interface) or graphicalContext (called owner in the Papyrus interface) (Papyrus integration)
+###*a context filtering rules to find diagram by semanticContext (called Root element in the Papyrus interface) or graphicalContext (called owner in the Papyrus interface) (Papyrus integration)
 ##''Papyrus NatTable''
 ###'''PapyrusTableView''': used to import a Papyrus table. It allows to define:
 ###*the type of the Table to include
@@ -102,21 +103,21 @@
 #Second level element
 ##''pure EMF''
 ###'''EClassPartTemplate''': to reference an EClass, to filter element found in the feature referenced in the previous level
-###'''InsertFileTemplate''': allow to declare a path to a file to integrate into the generated document. It won't be a reference, but a copy of its contents into the generated file.
+###'''InsertFileTemplate''': to declare a path to a file to integrate into the generated document. It won't be a reference, but a copy of its contents into the generated file.
 ##''UML''
-###'''StereotypePartTemplate''': allow to reference a stereotype, to filter element found in the feature referenced in the previous level
+###'''StereotypePartTemplate''': to reference a stereotype, to filter the elements found in the feature referenced in the previous level
 
 All the previous elements own these fields too:
-*''custom title'': a title to use instead of the default calculated title (generally the name of the feature, or the name/label of the element model)
+*''custom title'': a title to use instead of the default one (generally the name of the feature, or the name/label of the element model)
 *''generate title'': if <code>true</code>, a title will be generated
-*''generate'': if <code>true</code> we will generate something to this step, if <code>false</code>, we will generate nothing, but we will process its children. The 'View' elements have this field too, but this field is useless for them and should always be keep to <code>true</code>
-*''generateBranchCondition'': this field is not displayed in the property view. It is set when you create an Expression as child of the element. When a such condition is defined, the whole branch will be managed only when the condition will return <code>true</code> for the evaluated element. For more information about the Expression, please read the Papyrus Expression Framework.  
+*''generate'': if <code>true</code> we will generate something to this step, if <code>false</code>, we will generate nothing, but we will process its children. The 'View' elements have this field too, but this field is useless for them and should always be kept to <code>true</code>
+*''generateBranchCondition'': this field is not displayed in the property view. It is set when you create an Expression as child of the element. When such a condition is defined, the whole branch will be managed only when the condition will return <code>true</code> for the evaluated element. For more information about the Expression, please read the Papyrus Expression Framework.  
 On the next snapshot the process to create a new expression.  
 [[Image:images/userDoc/userDoc_002_CreateGenerateBranchCondition.png]]
 
 
 =How to create a TreeListView?=
-You can create a '''TreeListView''' as child element of the '''Body''' of your '''TextDocumentTemplate''' itself, or as child of an '''EClassPartTemplate''' or a '''StereotypePartTemplate'''.
+You can create a '''TreeListView''' as a child element of the '''Body''' of your '''TextDocumentTemplate''' itself, or as a child of an '''EClassPartTemplate''' or a '''StereotypePartTemplate'''.
 Under a '''TreeListView''', you can create, these elements:
 #''pure EMF''
 ##'''EReferenceListItemTemplate''': used to reference an EReference of the context model element of the list. The EReference value will be used to create the items in the document.
@@ -132,13 +133,13 @@
 ##'''StereotypeListItemTemplate''': used to reference a '''Stereotype''' to filter elements referenced by the feature from the previous level and create sub items. 
 
 =How to create an EReferenceTableView or a StereotypePropertyReferenceTableView?=
-A '''TableView''' allows you to display elements of your model with some of their properties' values. Your elements will be displayed as row : one row represents one element.
-You can create such '''TableView''' as child element of the '''Body''' of your '''TextDocumentTemplate''' itself, or as child of an '''EClassPartTemplate''' or a '''StereotypePartTemplate'''.
+A '''TableView''' allows you to display elements of your model with some of their properties' values. Your elements will be displayed as rows : one row representing one element.
+You can create such '''TableView''' as child elements of the '''Body''' of your '''TextDocumentTemplate''' itself, or as child of an '''EClassPartTemplate''' or a '''StereotypePartTemplate'''.
 Once one of these '''TableView ''' is created, you must fill these fields:
 *for '''EReferenceTableView''', the field '''EReference''' must be set. The value of this '''EReference''' will be used to create the rows of the table. 
 *for '''StereotypePropertyReferenceTableView''', the field '''propertyName''' and '''stereotypeQualifiedName''' must be set. The value of the '''propertyName''' will be used to create the rows of the table.
 
-Now we know how to obtain the rows, we need to declare the column. In order to do that, you need to create children for your '''TableView'''. Possible children are:
+Now that we know how to obtain the rows, we need to declare the column. In order to do that, you need to create new children for your '''TableView'''. Possible children are:
 #''pure EMF''
 ##'''EStructuralFeatureColumn''': you choose an EStructuralFeature
 #''UML''
@@ -153,19 +154,19 @@
 [[Image:images/userDoc/userDoc_003_CreateDocumentStructureFromDocumentTemplate.png]]
 
 An input dialog asking you the version of the DocumentStructure to generate opens. You must fill a string value (with char allowed for a file name), then Press ''Enter''.
-At the end of the process, an dialog opens to inform you about the end of the process.
-The generated '''DocumentStructure''' has been created. This file is visible in the ''Project Explorer'' View.
+At the end of the process, an dialog will open to inform you about the end of the process.
+The generated '''DocumentStructure''' has been created. This file should be visible in the ''Project Explorer'' View.
 
 [[Image:images/userDoc/userDoc_004_A_pds_file_appeas in the ProjectExplorer.png]]
 
 =How to generate the final Document from the DocumentStructure?=
 Open the generated '''*.pds''' file, then select the root element of the file (here, Text Document), then ''Right-Click''->''Generate ODT File''. 
-A dialog opens at the end of the process and the generated document appears in the ''Project Explorer'' view. (Sometimes, you need to refresh yourself the workspce, pressing F5).
+A dialog opens at the end of the process and the generated document appears in the ''Project Explorer'' view. (If it does not, you might need to refresh the workspace manually, pressing F5).
 
 
 =How to create a new LibreOffice template?=
 Here, we will talk about the ''*.ott'' file and not about the ''DocumentTemplate'' provided by Papyrus-Model2Doc.
-Of course, we advice you to read the LibreOffice documentation if required.
+Of course, we advise you to read the LibreOffice documentation as required.
 Your LibreOffice template can define styles, header and footer and more generally all features provided by LibreOffice.  
 
 The goal of this documentation chapter is to present you the LibreOffice field used by Model2Doc.