diff --git a/sections/experimentresults.tex b/sections/experimentresults.tex
index d8647843f104e611d49eb646b7d81018f7589034..ab20736655feff6bf2c32a5e92ee05991babd45e 100644
--- a/sections/experimentresults.tex
+++ b/sections/experimentresults.tex
@@ -1,4 +1,61 @@
 \chapter{Evaluation}\label{ch:evaluation}
 
-\input{sections/rq2}
-\input{sections/rq3}
\ No newline at end of file
+% Helpful attributes (Collection, inherited, easier return with =)
+During the implementation phase of parameter inference, RAG was beneficial at writing codes. At writing codes for parser and back-transformation, attributes could not be applied, because the functional parts change the structure of AST, which conflicts to the definition of attribute and also in JastAdd. So, it could not be realized that attributes can be practical. But, following attributes and features of JastAdd were helpful to construct the generators and implement them:
+
+\begin{itemize}
+\item As long as a returning value can be called or storable in primitive way, the syntax in RAG is reduced with an equals sign and simpler than in common programming language. Therefore, the source codes are compact. To compare how RAG could be implemented effectively, see the implementation of an attribute in this work in Listing 5.3 and how this attribute is defined in common Java description in Listing 5.4.
+\item To iterate all paths available in OpenAPI, an inherited attribute facilitated the writing effort. Paths Objects are child nodes of OpenAPI Object, so, all that should have been done was only two lines of code instead of writing an extra for loop. See Listing 5.5.
+\item As its name, Reference Attribute Grammar, every AST node can be referenced by an attribute. For instance, with a collection attribute. A reference defined in Listing 4.1 contains only a String variable named Ref, it still could provide its Object like in Listing 5.6.
+\end{itemize}
+
+\begin{lstlisting}[language=JRAG,label={lst:attribute-infParam},caption={Attribute InferredParameter.value()}]
+syn String InferredParameter.value() = getParameter().substring( getParameter().indexOf("?") + 1 );
+\end{lstlisting} 
+
+\begin{lstlisting}[language=JRAG,label={lst:java-infParam},caption={InferredParameter.value() in Java}]
+public String InferredParameter.value() {
+  return getParameter().substring( getParameter().indexOf("?") + 1 );
+}
+\end{lstlisting} 
+
+\begin{lstlisting}[language=JRAG,label={lst:inherited},caption={Inherited Attribute in Paths Object}]
+inh boolean PathsObject.inferUrl();
+eq OpenAPIObject.getPathsObject(int i).inferUrl(){
+  ...
+}
+\end{lstlisting} 
+
+\begin{lstlisting}[language=JRAG,label={lst:coll-param},caption={Collection Attribute in Parameter Object}]
+coll List<ParameterTuple> OpenAPIObject.parameterTuples() [new ArrayList<>()] root OpenAPIObject;
+  ParameterTuple contributes this
+  to OpenAPIObject.parameterTuples();
+...
+syn ParameterObject ParameterOb.parameterObject();
+eq ParameterObject.parameterObject() = this;
+eq ParameterReference.parameterObject() {
+  for( ParameterTuple t : root().parameterTuples() ){
+  if( t.getKey().equals(getRef().substring(getRef().lastIndexOf("/")+1, getRef().length())) )
+    return t.getParameterOb().parameterObject();
+  }
+  return new ParameterObject();
+}
+\end{lstlisting} 
+
+\begin{comment}
+RQ1 : Can we express approaches from related work? \\
+
+To answer this question, we 
+
+- test data structure and mapping \\
+- request generation \\
+- parameter inference \\
+- for future work: more approaches like analysis in RESTler, Constructing Operation Dependency Graph in RESTest, precise inference with stemming algor\\
+- \\
+- \\
+
+- RQ2 : What makes it easier to use RAGs than normal code, what makes it harder?\\
+- attributes for navigation/name resolution \\
+- implementing relative bigger and structured codes with small definitions\\
+- effort to be used to JastAdd\\
+\end{comment}
\ No newline at end of file
diff --git a/sections/introduction.tex b/sections/introduction.tex
index e95d29d34eabb92f4f88c894b11cfd32dbf768c0..95a6e09e190fbe89c1a9f3fd2c6c3d25db88a5b6 100644
--- a/sections/introduction.tex
+++ b/sections/introduction.tex
@@ -7,5 +7,12 @@ In the last years, the OpenAPI Specification has become the common way to docume
 OpenAPI specifications are described as JSON or YAML documents and are defined by a semi-formal specification describing permitted and required elements as well as their semantics. While there is no formal definition of the full OpenAPI language, a meta-schema exists for the JSON Schema parts of the language. \\ \\
 This paper investigates how such specifications can be used to test interfaces described by them. Since these specifications itself are tree-shaped, the investigation focuses on a grammar-based analysis approach, reference attribute grammars (RAGs). \\
 This paper also compares already presented REST API automatic testing approaches and examines whether these can also be implemented in RAGs, whether this implementation makes sense at all and whether RAG improves REST API automatic testing tools. \\
+
+\begin{description}
+\item{\textbf{RQ1}}
+\item{\textbf{RQ2}}
+\item{\textbf{RQ3}} 
+\end{description}
+
 The prototype implemented in this work provides simple evidences applying two testing approaches and results whether these approaches with RAG produce efficiencies in terms of compile speed and code coverage. \\
 For this work the meta-compilation system, JastAdd, is used to generate the RAG for the object-oriented programming language, Java.
diff --git a/sections/rq2.tex b/sections/rq2.tex
index d91f251b18ae2ca29bc7a9af7f7a75bff182555f..bc899a46400505cdf4bf3c6ef2df3922b8d1f845 100644
--- a/sections/rq2.tex
+++ b/sections/rq2.tex
@@ -1,5 +1,7 @@
 \section{Expression of approaches in RAG}
 
+
+
 RQ1 : Can we express approaches from related work? \\
 
 To answer this question, we