Index: /reasoner/reasoner.tex
===================================================================
--- /reasoner/reasoner.tex	(revision 128)
+++ /reasoner/reasoner.tex	(revision 129)
@@ -149,5 +149,4 @@
                                                        \undef & \text{else}\end{cases}
 $$
-To ease the definition of actual annotation values, IVML defines so called assignment blocks. An assignment block is a block that indicate the actual value of at least on annotation variable and applies the related value assignment to all variable declarations stated within the block. For the variable declarations appear as if they are directly defined within the containing element. For an arbitrary model element $e$, $isAssngBlock(e)$ returns whether $e$ is an assignment block. Moreover, 
 %
 \begin{multline*}
@@ -200,9 +199,7 @@
 \subsubsection{Project}
 
-A \emph{project} is a named scope, which can contain variable declarations, type declarations, assignment-blocks and eval-blocks. $varDeclarations(p)$ denotes the set of all variable declarations introduced in project $p$. $isProject(p)$ returns $true$ for a project $p$.
-
-$evals(p)$ is the set of (potentially nested) \emph{eval-blocks} in project $p$, i.e., if $e\in evals(p)$ then $constraints(e)$ is defined, but may be empty, similarly for $evals(e)$.
-
-Subsequently, he function $allEvalConstraints(e)$ collects all constraints stated in eval-block $e$ including all nested eval-blocks.
+A \emph{project} is a named scope, which can contain variable declarations, type declarations, assignment-blocks and eval-blocks. $decls(p)$ denotes the set of all variable declarations introduced in project $p$. $isProject(p)$ returns $true$ for a project $p$.
+
+$evals(p)$ is the set of (potentially nested) \emph{eval-blocks} in project $p$. If $e\in evals(p)$ then $constraints(e)$ returns the constraints listed in $e$, whereby $constraints(e)$ may be empty, in particular if $e$ is an arbitrary model element. Similarly, $evals(e)$ returns the nested eval-blocks. Subsequently, the function $allEvalConstraints(e)$ returns all constraints in eval-block $e$ including all nested eval-blocks.
 %
 \begin{align*}
@@ -211,7 +208,9 @@
 \end{align*}
 %
-In IVML, an \emph{annotation assignment} is a kind of block, which specifies the values for given annotations that will be implicitly assigned to all contained variable declarations. To allow orthogonal combinations of annotation assignments, assignment-blocks can be nested referring to different annotations. $assignments(p)$ is the set of (potentially nested) annotation assignments of project $p$. If $a\in assignments(p)$ then $varDeclarations(a)$ as well as $constraints(a)$ are defined, but may be empty, similarly for $assignments(a)$. $assignmentData(a)$ for an assignment $a$ provides access to the affected annotations and values, i.e., if $f \in assignmentData(a)$, $name(f)$ is the name of the affected attribute and $default(f)$ its the default value expression specifying the value to be assigned to all attributes with $name(f)$ for all declarations within the containing assignment-block. 
-
-Using these functions, the $allAssignmentConstraints(a)$ collects all the assignment constraints within an assignment $a$ considering potentially further nested assignment structures:
+In IVML, an \emph{annotation assignment} is a kind of block, which allows assigning annotation values to the variables defined within the block, i.e., the specified annotation values shall be applied to all contained variable declarations. The declared variables shall behave as if they are defined in the innermost containing element that is not an annotation assignment. For convenience, also constraints relating to the contained variable declarations can be stated within an annotation assignment. To indicate orthogonal combinations of annotation assignments in IVML models, annotation assignments can be nested referring to different annotations. For convenience, only the innermost annotation value assignment shall be applied in nested assignment blocks in order to avoid accidental multiple assignments to the same annotation within the same project scope.
+
+$assignments(p)$ is the set of (potentially nested) annotation assignments of project $p$. If $a\in assignments(p)$ then $decls(a)$ returns the variables declared in $a$ and $constraints(a)$ the constraints declared within $a$. Further, $assignments(a)$ returns the annotation assignments nested within $a$. All three results may be empty. Further, $assignmentData(a)$ provides access to the affected annotations and the intended values values, i.e., if $f \in assignmentData(a)$ then $name(f)$ is the name of the affected attribute and $default(f)$ the intended default value expression that shall be assigned to all attributes with name $name(f)$ for all declarations within the containing assignment-block. $isAnnotationAssignment(a)=true$ and for an arbitrary model element $e$, $isAnnotationAssignment(e)$ returns whether $e$ is an assignment block.
+
+Using these functions, $allAssignmentConstraints(a)$ determines all assignment constraints within an assignment $a$ considering potentially further nested annotation assignments:
 %
 \begin{align*}
@@ -220,20 +219,20 @@
 \end{align*}
 %
-Sometimes it is convenient to refer to a project as a pseudo-variable (of type \textit{Project}) with nested variables and annotations (declared for all contained variables). $variable(p)$ returns the declartion of this pseudo-variable for a given project $p$. Using this pseudo-variable, we can define how to find an attribute declaration with name $n$ that is directly attributed to variable $v$ or one of the containing scopes of $v$:
+In some algorithms we need to determine an attribute attribute declaration with name $n$ that is directly attributed to variable $v$ or one of the containing scopes of $v$. While for nested variables, we can just take the parent variables into account, this ends with the containing project. For ease of access, we (internally) represent a project as a (pseudo-)variable $variable(p)$ containing all variables declared by the project as nested variable. Then
 %
 \begin{multline*}
-findAnnotation(v, n) = \begin{cases}
-  annotation(v, n), &\text{if } annotation(v, n) \neq \undef\\
-  findAnnotation(parent(v), n), &\text{if } isVariable(parent(v))\\
-  findAnnotation(variable(parent(v)), n), &\text{if } isProject(parent(v))\\
-  \undef, & \text{else} \\  
+findAnnotation(v, n) = \\ \ \ \begin{cases}
+  annotation(v, n) &\text{if } annotation(v, n) \neq \undef\\
+  findAnnotation(parent(v), n) &\text{if } isVariable(parent(v))\\
+  findAnnotation(variable(parent(v)), n) &\text{if } isProject(parent(v))\\
+  \undef & \text{else} \\  
   \end{cases}
 \end{multline*}
 %
-returns the innermost annotation for $v$ with name $n$.
+returns the innermost annotation for variable $v$ with name $n$.
 %
 \subsubsection{Constraints}\label{sectNotationConstraints}
 
-A \emph{constraint} is a Boolean expression that must always evaluate to $true$. Otherwise, reasoning shall either fail or, after a change of at least one of the involved variables, the constraint shall be re-evaluated potentially wiping out previous reasoning errors for that constraint. A constraint consists of expressions, that can evaluate to values of some type supported by IVML. These expressions can be used to determine the default value of variables. 
+In IVML, a \emph{constraint} is a Boolean expression that must always evaluate to $true$. Otherwise, reasoning shall either fail or, after a change of at least one of the variables involved in the constraint, the constraint shall be re-evaluated potentially wiping out previous reasoning errors for that constraint. A constraint consists of expressions, that can evaluate to values of some type supported by IVML. These expressions can be used to determine the default value of variables. 
 
 Moreover, \IVML{Constraint} is an IVML type, indicating that a variable actually holds a constraint. From the reasoning point of view, a constraint stored as a value in a constraint variable is evaluated as any other constraint. However, the value in such a variable may, as for all other variables, be undefined, frozen, or re-defined (once per project scope) implying that the old constraint must be discarded or even replaced by the new constraint value and considered by the reasoning process.
@@ -516,5 +515,5 @@
 
      \tcp{start of model visitor}%>ConstraintTranslationVisitor
-     \ForAll{$d \iterAssng varDeclarations(p)$}{ \label{algTranslateConstraintsTranslationStart}
+     \ForAll{$d \iterAssng decls(p)$}{ \label{algTranslateConstraintsTranslationStart}
         $translateDeclaration(d, decision(cfg, d), \undef)$\; \label{algTranslateConstraintsTranslationDeclaration}
       }
@@ -653,5 +652,5 @@
           \lIf{$ca \neq \undef$}{$s \assng ca$} \label{algTranslateDeclarationTranslateInCompound}
       }\lElseIf{$inc \wedge \neg isContainer(t)$}{$ dflt \assng \undef $}
-      \If{$ deflt \neq \undef \wedge \neg(isAttribute(d) \wedge isAssngBlock(parent(d)))$}{ 
+      \If{$ deflt \neq \undef \wedge \neg(isAttribute(d) \wedge isAnnotationAssignment(parent(d)))$}{ 
           \uIf{$isConstraint(type(d))$}{ \label{algTranslateDeclarationTranslateConstraintDefaultStart}
               $createConstraintVariableConstraint(dflt, s, v)$\; \label{algTranslateDeclarationConstraintVariableConstraint}