Fixed migration documentation URL.
diff --git a/documentation/aql.html b/documentation/aql.html
index 7712e7d..1a34418 100644
--- a/documentation/aql.html
+++ b/documentation/aql.html
@@ -22,4 +22,4 @@
QueryCompletionEngine engine = new QueryCompletionEngine(queryEnvironment);
ICompletionResult completionResult = engine.getCompletion("self.", 5, variableTypes);
List<ICompletionProposal> proposals = completionResult.getProposals(new BasicFilter(completionResult));
-</code></pre><p>Here 5 is the offset where the completion should be computed in the given expression.</p><h2 id="MigratingfromMTLqueries">Migrating from MTL queries</h2><p>As languages, AQL and MTL are very close yet there are some notable differences:</p><h3 id="Implicitvariablereferences">Implicit variable references</h3><p>There is no implicit variable reference. With this change, you can easily find out if you are using a feature of an object or a string representation of said object. As a result, instead of using «[something/]», you must use «self.something» if you want to access the feature named «something» of the current object or «something» if you want to retrieve the object named something.</p><p>In a lambda expression, you must now define the name of the variable used for the iteration in order to easily identify which variable is used by an expression. In Acceleo MTL, you can write «Sequence{self}->collect(eAllContents(uml::Property))» and Acceleo will use the implicit iterator as a source of the operation eAllContents.</p><p>The problem comes when using a lambda like «Sequence{self}->collect(something)», we can’t know if «something» is a feature of «self» or if it is another variable.</p><p>Using AQL, you will now have to write either «collect(m | m.eAllContents(uml::Property))» or «collect(m: uml::Model | eAllContents(uml::Property))».</p><h3 id="Collectandflatten">Collect and flatten</h3><p>When a call or a feature acces is done on a collection the result is flattened for the first level. For instance a service returning a collection called on a collection will return a collection of elements and not a collection of collection of elements.</p><h3 id="TypeliteralschildrenEPackages">Type literals & children EPackages</h3><p>Type literals can’t be in the form someEPackage::someSubEPackage::SomeEClass but instead someSubEPackage::SomeEClass should be directly used. Note that the name of the EPackage is now mandatory.</p><h3 id="TypeliteralschildrenEPackages2">Type literals & children EPackages</h3><p>Enumeration literal should be prefixed with the name of the containing EPacakge for instance «myPacakge::myEnum::value».</p><h3 id="Collections">Collections</h3><p>You can only have Sequences or OrderedSets as collections and as such the order of their elements is always deterministic. In Acceleo MTL, you had access to Sets, which are now OrderedSets and Bags, which are now Sequences. Those four kinds of collections were motivated by the fact that Sequence and OrderedSet were ordered contrary to Sets and Bags. On another side, OrderedSets and Sets did not accept any duplicate contrary to Bags and Sequences.</p><p>By careful reviewing the use of those collections in various Acceleo generators and Sirius Designers we have quickly found out that the lack of determinism in the order of the collections Sets and Bags was a major issue for our users. As a result, only two collections remain, the Sequence which can contain any kind of element and the OrderedSet which has a similar behavior except that it does not accept duplicates.</p><p>Previously in Acceleo MTL, you could transform a literal into a collection by using the operator «->» on the literal directly. In Acceleo MTL, the collection created was a Bag which is not available anymore. It is recommended to use the extension notation like «Sequence{self}» or «OrderedSet{self}». By default in AQL the created collection is an OrderedSet.</p><h3 id="Renamedoperations">Renamed operations</h3><p>Some operations have been renamed. As such «addAll» and «removeAll» have been renamed «add» and «sub» because those two names are used by AQL in order to provide access to the operator «+» and «-». As a result we can now write in AQL «firstSequence + secondSequence» or «firstSet - secondSet».</p><h3 id="Typing">Typing</h3><p>AQL is way smarter than MTL regarding to the types of your expressions. As a result, you can combine expressions using multiple types quite easily. For example, this is a valid AQL expression «self.eContents(uml::Class).add(self.eContents(ecore::EClass)).name». In Acceleo MTL, we could not use this behavior because Acceleo MTL had to fall back to the concept EObject which does not have a feature «name» while AQL knows that the collection contains objects that are either «uml::Class» or «ecore::EClass» and both of those types have a feature named «name».</p><h3 id="nullhandling">null handling</h3><p>AQL handles null (OclVoid) differently from ocl, so «oclIsUndefined» should be mostly useless for AQL expressions. For example, «null.oclIsKindOf(ecore::EClass)» would have returned true for MTL/OCL, forcing users to use «not self.oclIsUndefined() and self.oclIsKindOf(ecore::EClass)» instead. This is no longer true in AQL, where «null» doesn't conform to any type, so «null.oclIsKindOf(ecore::EClass)» will return false. Note that it's still possible to cast null into any given classifier. «null.oclAsType(ecore::EClass)» will not fail at runtime.</p><h2 id="MigratingfromAcceleo2queries">Migrating from Acceleo2 queries</h2><h3 id="EClassifierreferences">EClassifier references</h3><p>All operations referencing a type are now using a type literal with the name of the EPackage and the name of the type instead of a string with the name of the type. As a result, «eObject.eAllContents('EClass')» would be translated using "eObject.eAllContents(‹ecore::EClass›). This allows AQL to now in which EPackage to look for the type and as such, it improves the quality of the validation.</p><h3 id="Typesandcast">Types and cast</h3><p>In order to test the type of an EObject, a common pattern in Acceleo 2 was to treat the EObject as a collection and filter said collection on the type desired to see if the size of the collection changed. In AQL, you have access to the operations oclIsTypeOf and oclIsKindOf. You can thus test the type of an EObject with the expression «eObject.oclIsKindOf(ecore::EStructuralFeature)» or «eObject.oclIsTypeOf(ecore::EAttribute)». You can use the operation oclIsKindOf to test if an object has the type of the given parameter or one of its subtype. On the other hand, you can use the operation oclIsTypeOf to test if an object has exactly the type of the given parameter.</p><p>Casting in AQL is useless, since AQL is very understandable when it comes to types, it will always tries its best to evaluate your expression.</p><p>Since AQL is very close to Acceleo MTL, you can find some additional documentation using the Acceleo equivalence documentation in the <a href="http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.acceleo.doc%2Fdoc%2Fhtml%2Facceleo_equivalence.html">Acceleo documentation</a>.</p></body></html>
\ No newline at end of file
+</code></pre><p>Here 5 is the offset where the completion should be computed in the given expression.</p><h2 id="MigratingfromMTLqueries">Migrating from MTL queries</h2><p>As languages, AQL and MTL are very close yet there are some notable differences:</p><h3 id="Implicitvariablereferences">Implicit variable references</h3><p>There is no implicit variable reference. With this change, you can easily find out if you are using a feature of an object or a string representation of said object. As a result, instead of using «[something/]», you must use «self.something» if you want to access the feature named «something» of the current object or «something» if you want to retrieve the object named something.</p><p>In a lambda expression, you must now define the name of the variable used for the iteration in order to easily identify which variable is used by an expression. In Acceleo MTL, you can write «Sequence{self}->collect(eAllContents(uml::Property))» and Acceleo will use the implicit iterator as a source of the operation eAllContents.</p><p>The problem comes when using a lambda like «Sequence{self}->collect(something)», we can’t know if «something» is a feature of «self» or if it is another variable.</p><p>Using AQL, you will now have to write either «collect(m | m.eAllContents(uml::Property))» or «collect(m: uml::Model | eAllContents(uml::Property))».</p><h3 id="Collectandflatten">Collect and flatten</h3><p>When a call or a feature acces is done on a collection the result is flattened for the first level. For instance a service returning a collection called on a collection will return a collection of elements and not a collection of collection of elements.</p><h3 id="TypeliteralschildrenEPackages">Type literals & children EPackages</h3><p>Type literals can’t be in the form someEPackage::someSubEPackage::SomeEClass but instead someSubEPackage::SomeEClass should be directly used. Note that the name of the EPackage is now mandatory.</p><h3 id="TypeliteralschildrenEPackages2">Type literals & children EPackages</h3><p>Enumeration literal should be prefixed with the name of the containing EPacakge for instance «myPacakge::myEnum::value».</p><h3 id="Collections">Collections</h3><p>You can only have Sequences or OrderedSets as collections and as such the order of their elements is always deterministic. In Acceleo MTL, you had access to Sets, which are now OrderedSets and Bags, which are now Sequences. Those four kinds of collections were motivated by the fact that Sequence and OrderedSet were ordered contrary to Sets and Bags. On another side, OrderedSets and Sets did not accept any duplicate contrary to Bags and Sequences.</p><p>By careful reviewing the use of those collections in various Acceleo generators and Sirius Designers we have quickly found out that the lack of determinism in the order of the collections Sets and Bags was a major issue for our users. As a result, only two collections remain, the Sequence which can contain any kind of element and the OrderedSet which has a similar behavior except that it does not accept duplicates.</p><p>Previously in Acceleo MTL, you could transform a literal into a collection by using the operator «->» on the literal directly. In Acceleo MTL, the collection created was a Bag which is not available anymore. It is recommended to use the extension notation like «Sequence{self}» or «OrderedSet{self}». By default in AQL the created collection is an OrderedSet.</p><h3 id="Renamedoperations">Renamed operations</h3><p>Some operations have been renamed. As such «addAll» and «removeAll» have been renamed «add» and «sub» because those two names are used by AQL in order to provide access to the operator «+» and «-». As a result we can now write in AQL «firstSequence + secondSequence» or «firstSet - secondSet».</p><h3 id="Typing">Typing</h3><p>AQL is way smarter than MTL regarding to the types of your expressions. As a result, you can combine expressions using multiple types quite easily. For example, this is a valid AQL expression «self.eContents(uml::Class).add(self.eContents(ecore::EClass)).name». In Acceleo MTL, we could not use this behavior because Acceleo MTL had to fall back to the concept EObject which does not have a feature «name» while AQL knows that the collection contains objects that are either «uml::Class» or «ecore::EClass» and both of those types have a feature named «name».</p><h3 id="nullhandling">null handling</h3><p>AQL handles null (OclVoid) differently from ocl, so «oclIsUndefined» should be mostly useless for AQL expressions. For example, «null.oclIsKindOf(ecore::EClass)» would have returned true for MTL/OCL, forcing users to use "not self.oclIsUndefined() and self.oclIsKindOf(ecore::EClass) instead. This is no longer true in AQL, where «null» doesn’t conform to any type, so «null.oclIsKindOf(ecore::EClass)» will return false. Note that it’s still possible to «cast» null in any given classifier. «null.oclAsType(ecore::EClass)» will not fail at runtime.</p><h2 id="MigratingfromAcceleo2queries">Migrating from Acceleo2 queries</h2><h3 id="EClassifierreferences">EClassifier references</h3><p>All operations referencing a type are now using a type literal with the name of the EPackage and the name of the type instead of a string with the name of the type. As a result, «eObject.eAllContents('EClass')» would be translated using "eObject.eAllContents(‹ecore::EClass›). This allows AQL to now in which EPackage to look for the type and as such, it improves the quality of the validation.</p><h3 id="Typesandcast">Types and cast</h3><p>In order to test the type of an EObject, a common pattern in Acceleo 2 was to treat the EObject as a collection and filter said collection on the type desired to see if the size of the collection changed. In AQL, you have access to the operations oclIsTypeOf and oclIsKindOf. You can thus test the type of an EObject with the expression «eObject.oclIsKindOf(ecore::EStructuralFeature)» or «eObject.oclIsTypeOf(ecore::EAttribute)». You can use the operation oclIsKindOf to test if an object has the type of the given parameter or one of its subtype. On the other hand, you can use the operation oclIsTypeOf to test if an object has exactly the type of the given parameter.</p><p>Casting in AQL is useless, since AQL is very understandable when it comes to types, it will always tries its best to evaluate your expression.</p><p>Since AQL is very close to Acceleo MTL, you can find some additional documentation using the Acceleo equivalence documentation in the <a href="http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.acceleo.doc%2Fpages%2Freference%2Fmigration.html&cp=5_3_4">Acceleo documentation</a>.</p></body></html>
\ No newline at end of file
diff --git a/documentation/aql.textile b/documentation/aql.textile
index d604155..cb90138 100644
--- a/documentation/aql.textile
+++ b/documentation/aql.textile
@@ -190,4 +190,4 @@
Casting in AQL is useless, since AQL is very understandable when it comes to types, it will always tries its best to evaluate your expression.
-Since AQL is very close to Acceleo MTL, you can find some additional documentation using the Acceleo equivalence documentation in the "Acceleo documentation":http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.acceleo.doc%2Fdoc%2Fhtml%2Facceleo_equivalence.html.
+Since AQL is very close to Acceleo MTL, you can find some additional documentation using the Acceleo equivalence documentation in the "Acceleo documentation":http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.acceleo.doc%2Fpages%2Freference%2Fmigration.html&cp=5_3_4.
