Index: /reasoner/reasoner.tex =================================================================== --- /reasoner/reasoner.tex (revision 72) +++ /reasoner/reasoner.tex (revision 73) @@ -155,7 +155,23 @@ \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$. $evals(p)$ is the set of (potentially nested) 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)$. - -An annotation assignment is a 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. +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$. + +$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. +% +\begin{align*} +all&EvalConstraints(e) = \\ + &constraints(e) \cup \setWith{allEvalConstraints(f)}{f \in evals(e)} +\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: +% +\begin{align*} +all&AssignmentConstraints(a) = \\ + &constraints(a) \cup \setWith{allAssignmentConstraints(b)}{b \in assignments(a)} +\end{align*} \subsubsection{Constraints}\label{sectNotationConstraints} @@ -177,10 +193,10 @@ \subsubsection{Compounds}\label{sectNotationCompounds} -A \emph{compound} is an IVML type, which consists of variable declarations, called slots. Let $t$ be a compound type, then $isCompound(t)$ returns $true$, else for all other types $false$. The slots of a compound $t$ can be accessed through $slots(t)$. Akin to a variable declaration, for slot $s$ $name(s)$, $default(s)$ and $type(s)$ are defined. Moreover, let $v$ be a compound variable, i.e., a variable of a compound type $t$, then $decision(v, s)$ returns the variable related to slot $s$ in the configuration $v$ is a member of. $slots(v)$ is definied similarly to $slots(t)$, but contains all slots of the variable, i.e., including those inherited from refined compounds and those declared within assignment blocks nested within the declaration of the compound type $t$. For convenience, we introduce +A \emph{compound} is an IVML type, which consists of variable declarations, called slots. Let $t$ be a compound type, then $isCompound(t)$ returns $true$, else for all other types $false$. The slots of a compound $t$ can be accessed through $slots(t)$. Akin to a variable declaration, for slot $s$ $name(s)$, $default(s)$ and $type(s)$ are defined. Moreover, let $v$ be a compound variable, i.e., a variable of a compound type $t$, then $decision(v, s)$ returns the variable related to slot $s$ in the configuration $v$ is a member of. $slots(v)$ is definied similarly to $slots(t)$, but contains all slots of the variable, i.e., including those inherited from refined compounds and those declared within assignment-blocks nested within the declaration of the compound type $t$. For convenience, we introduce $$dfltSlots(v) = \setWith{s}{s\in slots(v) \wedge default(s) \neq \undef}$$ %, compound slots of $v$ having default value expressions, empty for all non-compound types -Compounds can form an inheritance hierarchy through multiple inheritance. Individual slots from parent compounds can thereby shadowed / redefined by slots of the same or more specific type. $refines(t)$ represents the set of compound types directly refined by \TBD{refining?} compound $t$, returning an empty set if there are no such compounds or if $t$ is not a compound type. We define - +Compounds can form an inheritance hierarchy through multiple inheritance. Individual slots from parent compounds can thereby shadowed / redefined by slots of the same or more specific type. $refines(t)$ represents the set of compound types directly refined by compound $t$, returning an empty set if there are no such compounds or if $t$ is not a compound type. We define +% $$allRefines(t) = \begin{cases} @@ -189,7 +205,7 @@ \end{cases} $$ - +% as the set of all refined compounds along the compound refinement / inheritance hierarchy of $t$ and - +% $$allRefines^+(t) = \begin{cases} @@ -197,24 +213,43 @@ \emptySet, & \text{else} \end{cases}$$ - -as the set of all refined compounds along the compound refinement / inheritance hierarchy of $t$ including $t$. All inherited slots can then be derived by - -$$inheritedSlots(t) = \setWith{slots(r)}{r\in allRefines^+(t)}$$ - +% +as the set of all refined compounds along the compound refinement / inheritance hierarchy of $t$ including $t$. Based on these functions, the set of all slots for compound type $t$ can be derived by +% +$$slots^+(t) = \setWith{slots(r)}{r\in allRefines^+(t)}$$ +% +All declared compound constraints\footnote{The implementation unifies $allCompoundConstraints(t)$ with $allVariableConstraints(t)$ distinguished by a boolean parameter. We differentiate them here to indicate the sets to be transformed more clearly.} for compound type $t$ are +% +\begin{align*} +all&CompoundConstraints(t) = \\ + &\setWith{constraints(s) \cup allAssignmentConstraints(s)}{t \in allRefines^+(t)} +\end{align*} +% +and all constraints stemming from constraint variables for $t$ +% +\begin{align*} +all&VariableConstraints(t) = \setWith{\createConstraint{s}}{s\in slots^+(t) \wedge isConstraint(type(s))}\text{ } +\end{align*} +% In some constraint transformations it is important to determine, whether a variable declaration, i.e., in particular for a compound slot is overridden. Let $d$ be a declaration, in particular $d\in slots(t) \wedge isCompund(t)$, then the parent compound of $d$ is - -$$parentCompound(d) = - \begin{cases} +% +\begin{align*} +parent&Compound(d) = \\ + &\begin{cases} parent(d), & \begin{aligned}\text{if }& parent(d) \neq \undef \wedge{}\\ &isCompound(parent(d)) \end{aligned}\\ parentCompound(parent(d)), & \text{if } parent(d) \neq \undef \\ \undef, & \text{else} - \end{cases}$$ + \end{cases} +\end{align*} and we can determine whether $d$ is overridden by - +% $$isOverridden(d) = d \in \setWith{slots(r)}{r\in allRefines(parentCompound(d))}$$ -Akin to projects, $assignments(t)$ is defined for a compound type $t$ and returns the annotation assignment blocks. Similar functions apply to access the constraints, the variable declarations and the assignment data. - +Akin to projects, $assignments(t)$ is defined for a compound type $t$ and returns the annotation assignment-blocks and $evals(t)$ all eval-blocks nested in $t$. Further, for $t$, constraints for all nested eval-blocks can be obtained using +% +\begin{equation*} + allEvalConstraints(t) = \bigcup_{e\in evals(t)}{allEvalConstraints(e)} +\end{equation*} +% \emph{Accessors} to compound variables define a path to access a certain slot within that variable, i.e., an accessor must mention the variable and the slot to access. Let \IVML{cmp} be an IVML variable of compound type, then an accessor to slot \IVML{slot} looks in IVML notation like \IVML{cmp.slot}. If \IVML{slot} is in turn of compound type, also nested accessors may occur, e.g., \IVML{cmp.slot1.slot2}. For creating such expressions, we use the IVML operation \IVML{acc}\footnote{Actually, a constructor call to create an accessor expression tree node.}. Then, following the expression creation notation from Section \ref{sectNotationConstraints}, creating the first accessor within an IVML expression can be expressed by $\createExpression{\IVMLMeta{acc}\IVML{(cmp, slot)}}$, while for the second accessor we use $\createExpression{\IVMLMeta{acc}(\IVMLMeta{acc}(\IVML{cmp}, \IVML{slot}),\IVML{slot2})}$. @@ -413,6 +448,4 @@ \end{algorithm} -%----------------------------------------------------------------------------------------------------------------- - \section{Constraint translation}\label{sectTranslation} @@ -420,5 +453,5 @@ \begin{enumerate} - \item Explicit \emph{top-level constraints} written by the domain expert, which are already using qualified variables. This group of constraints includes also constraints in top-level (nested) eval blocks as well as constraints in top-level annotation assignment blocks. Top-level constraints, eval-block constraints and annotation assignment constraints are ready for reasoning, do not need further translation and can directly be taken over into the constraint base (Algorithm \ref{algTranslateConstraints}, lines \ref{algTranslateConstraintsAdd} - \ref{algTranslateConstraintsTopLevelEvals}). As annotation assignments typically also include variable declarations, we enumerate them through a specific algorithm, which is also used for translating annotation assignments in compound types. However, we pass here parameters that focus on enumerating and adding rather than translating the related constraints. + \item Explicit \emph{top-level constraints} written by the domain expert, which are already using qualified variables. This group of constraints includes also constraints in top-level (nested) eval blocks as well as constraints in top-level annotation assignment-blocks. Top-level constraints, eval-block constraints and annotation assignment constraints are ready for reasoning, do not need further translation and can directly be taken over into the constraint base (Algorithm \ref{algTranslateConstraints}, lines \ref{algTranslateConstraintsAdd} - \ref{algTranslateConstraintsTopLevelEvals}). As annotation assignments typically also include variable declarations, we enumerate them through a specific algorithm, which is also used for translating annotation assignments in compound types. However, we pass here parameters that focus on enumerating and adding rather than translating the related constraints. \item \emph{Constraints introduced through variable types}, e.g., compound types. These constraints must be instantiated through translation, i.e., use of type level variables and slots must be rewritten to use actual variables and slots. Here, we start from top-level variable variables and perform a transitive instantiation based on the respective type of the variable. Where possible, it is important to consider the actual type of the value of the individual variables, as through type compatibility of refined types, the actual value type may be more specific that the declared type of the variable. This is initiated in Algorithm \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTopLevelAnnotationAssignments}. \item \emph{Constraints for default values}. To achieve uniformity of the constraint evaluation and variable update process (cf. Section \ref{sectReasoning}), we (currently) translate default value assignments to assignment constraints. In more detail, the IVML declaration \IVML{Type v = ex;} must be translated into a constraint $\createConstraint{v = ex}$. We add these assignment constraints to the constraint base with higher priority than other constraints to ensure that default values are assigned first. Here, we must consider that default value assignments can change the actual value type implying that a refined set of constraints must be evaluated on the respective variable. Moreover, default value expressions for complex values shall have more priorities than default values for individual slots, as otherwise the default value for the individual slot (e.g., given as default value within a compound or a refined slot) may be overridden by a complex value from a containing scope, e.g., a top-level variable declaration. This is also initiated in Algorithm \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTopLevelAnnotationAssignments}. @@ -496,11 +529,12 @@ \subsection{Compound constraints}\label{sectCompoundDefaults} -Translating a compound into all its constraints requires considering all slots including inherited slots, all constraints defined within a compound including inherited ones, as well as all nested structures, such as eval blocks or attribute value assignment blocks. In particular, if the IVML keyword \IVMLself{} is used, it must be replaced by the actual variable of the respective compound type. Moreover, it is important to recall that a variable $v$ of type $type(v)$ can contain instances of any refined type $allRefines^+(t)$, and in this case the translation must consider the default values of the potentially larger slot, additional constraints and nested structures. - -Algorithm \ref{algTranslateCompoundDeclaration} consists of three parts: +Translating a compound into all its constraints requires considering all slots including inherited slots, all constraints defined within a compound including inherited ones, as well as all nested structures, such as eval blocks or attribute value assignment-blocks. In particular, if the IVML keyword \IVMLself{} is used, it must be replaced by the actual variable of the respective compound type. Moreover, it is important to recall that a variable $v$ of type $type(v)$ can contain instances of any refined type $allRefines^+(t)$, and in this case the translation must consider the default values of the potentially larger slot, additional constraints and nested structures. + +Algorithm \ref{algTranslateCompoundDeclaration} translates the default constraints for a compound variable $v$ with declaration $d$, potential compound accessor $ca$ and (default value) type (or $type(d)$ if no default expression is defined for $d$). The types are related by $type(d) = type(v) \in allRefines^+(t)$. Algorithm \ref{algTranslateCompoundDeclaration} consists of three parts: +% \begin{enumerate} \item Creation and registration of access expressions to all slots and attributes so that cross references can be implicitly resolved during variable substitution applied to all default value expressions and constraints. \item Translating all slot declarations and attributes using Algorithm \ref{algTranslateDeclaration}. -\item Translating all nested annotation assignment blocks $\otherConstraints$ as value assignment constraints (if not in incremental mode). +\item Translating all nested annotation assignment-blocks $\otherConstraints$ as value assignment constraints (if not in incremental mode). \item Translating all nested eval blocks to $\otherConstraints$. \item Translating all compound related constraints to $\otherConstraints$. @@ -530,47 +564,12 @@ \leIf{$ca \neq \undef$}{$f\assng ca$}{$f\assng d$} $add(\otherConstraints, \setWith{\createConstraint{\varSubstitutionSelfVarMapping{f}{c}}}{c\in \bigcup_{r\in allRefines^+(t)} allEvalConstraints(r)}, true)$\; - $add(\otherConstraints, \setWith{\createConstraint{\varSubstitutionSelfVarMapping{c}{f}}}{c\in allCompoundConstraints(t, false)}, true)$\; + $add(\otherConstraints, \setWith{\createConstraint{\varSubstitutionSelfVarMapping{c}{f}}}{c\in allCompoundConstraints(t)}, true)$\; \caption{Translating compound declarations (\IVML{translateCompoundDeclaration}).}\label{algTranslateCompoundDeclaration} \end{algorithm} -Finally, the algorithm translates the nested structures. Then it translates all annotation value assignments using Algorithm \ref{algTranslateAnnotationAssignments}. For the last two translations, we need the actual value of \IVMLself{}, to be determined for the recent compound, either based on the given accessor $ca$ or the declaration $d$. Then, to keep the priority of eval-blocks, it collects all constraints of all nested eval-blocks, replaces \IVMLself{} and variable mappings $\variableMapping$ and adds them to $\otherConstraints$. Finally, we take over and translate all constraints of all transitively declared constraints refined compounds, constraint variables, and assignment constraints. - -Algorithm \ref{algTranslateCompoundDeclaration} uses various functions, which we define for completeness below. - -\MISSING{---HERE---} - -%Expressions may be simple variables, calculations or operation calls, in compounds also using the predefined variable \texttt{self} indicating the actual instance of the respective compound. These constraints must be evaluated upon each variable instance, i.e., for top-level basic variables, top-level compound variables, compound values within compounds as well as compound values within container initialiers, each potentially with a different access expression to make the variable unique. - -The function $allAssignmentConstraints(a)$ collects all the assignment constraints within an assignment $a$ considering potentially further nested assignment structures: -% -\begin{align*} -all&AssignmentConstraints(a) = \\ - &constraints(a) \cup \setWith{allAssignmentConstraints(b)}{b \in assignments(a)} -\end{align*} -% -Similarly, the function $allEvalConstraints(e)$ collects all constraints stated in \IVML{eval} blocks nested in the \IVML{eval} block $e$. -% -\begin{align*} -all&EvalConstraints(e) = \\ - &constraints(e) \cup \setWith{allEvalConstraints(f)}{f \in evals(e)} -\end{align*} -% -If $isCompound(t)$, all nested eval constraints within a compound $t$ can be enumerated using -% -\begin{equation*} - allEvalConstraints(t) = \bigcup_{e\in evals(t)}{allEvalConstraints(e)} -\end{equation*} -% -Moreover, he function $allCompoundConstraints(t, b)$ collect all constraints defined a compound type $t$. This includes the directly defined constraints, the constraints stemming from inherited constraint variables, the refined compound constraints and all constraints in (nested) assignment environments. Parameter $b$ is just used to indicate whether the function is called recursively, i.e., to collect constraint variables only directly for $t$. \TBD{Why not constraint variables via refines?} -% -\begin{align*} -all&CompoundConstraints(t, b) = constraints(t)\text{ }\cup \\ - &\closedCases{\setWith{\createConstraint{s}}{s\in inheritedSlots(t) \wedge isConstraint(type(s))}, & \text{if } b \\ \setEmpty, &\text{else}} \cup \\ - &\setWith{getAllCompoundContraints(r, false)}{r \in refines(t)} \cup \\ - &{allAssignmentConstraints(assignments t)} -\end{align*} -% -Algorithm \ref{algTranslateCompoundDeclaration} translates the default constraints for a compound variable $v$ with declaration $d$, potential compound accessor $ca$ and (default value) type (or $type(d)$ if no default expression is defined for $d$). The types are related by $type(d) = type(v) \in allRefines^+(t)$. +Finally, the algorithm translates the nested structures. Then it translates all annotation value assignments using Algorithm \ref{algTranslateAnnotationAssignments}. For the last two translations, we need the actual value of \IVMLself{}, to be determined for the recent compound, either based on the given accessor $ca$ or the declaration $d$. Then, to keep the priority of eval-blocks, it collects all constraints of all nested eval-blocks, replaces \IVMLself{} and variable mappings $\variableMapping$ and adds them to $\otherConstraints$. Finally, we take over and translate all constraints of all transitively declared constraints refined compounds and assignment constraints. + +%----------------------------------------------------------------------------------------------------------------- \subsection{Container constraints}\label{sectContainerDefaults} @@ -642,5 +641,5 @@ $\variableMapping \assng \variableMapping \addMap \mapEntry{s}{\createExpression{\IVMLMeta{acc}(v,s)}}$\; } - \ForAll{$e \iterAssng allCompoundConstraints(t)$} { + \ForAll{$e \iterAssng allCompoundConstraints(t) \cup allVariableConstraints(t)$} { $coll \assng\createExpression{\closedCases{ca, & \text{if } ca = \undef \\ d, &\text{else}}}$\; $coll \assng\createExpression{coll.\closedCases{\IVML{selectByKind}(a, t), & \text{if } t \neq dt \\ &\text{else}}}$\; @@ -654,5 +653,5 @@ \subsection{Annotations}\label{sectAnnotationDefaults} -In IVML, annotations are orthogonal typed variables that can be attached to a variable. For all those ortogonal variables, the reasoner must create constraints to perform the evaluation and assignment of the default values before all other constraints are considered for reasoning. Moreover, we must translate assignment blocks, i.e., blocks assigning specific values to all variables declared within that block. In this section, we discuss first the translation of annotations, then the translation of annotation blocks. +In IVML, annotations are orthogonal typed variables that can be attached to a variable. For all those ortogonal variables, the reasoner must create constraints to perform the evaluation and assignment of the default values before all other constraints are considered for reasoning. Moreover, we must translate assignment-blocks, i.e., blocks assigning specific values to all variables declared within that block. In this section, we discuss first the translation of annotations, then the translation of annotation blocks. Algorithm \ref{algTranslateAnnotationDeclarations} receives the declaration of the actual variable and a potential compound access expression $ca$ to $d$ if the algorithm is called for slots of a compound value. For all annotations of $v$ (as for $v$ here all inherited annotations are available), the algorithm creates the respective constraints through calling Algorithm \ref{algTranslateDeclaration}. Plase note that no specific variable accessors are handled for such top-level annotation assignments through a specific constraint syntax tree node, which is created through \IVMLMeta{acc()} in Algorithm \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateAnnotationAccess}. @@ -669,14 +668,14 @@ \end{algorithm} -We turn now to the translation of annotation assignment blocks. In IVML, an assignment block is used on top-level or within compounds to declare compound slots with an implicit assignment of a value to each declared annotation. Further, assignment blocks can be nested and the assignments defined for the outer blocks must be applied also to the inner blocks. - -The translation of assignment blocks on top-level is triggered by Algorithm \ref{algTranslateConstraints} in line \ref{algTranslateConstraintsTopLevelAnnotationAssignments}. The translation of assignment blocks within compounds is caused by Algorithm \ref{algTranslateCompoundDeclaration} in line \ref{algTranslateCompoundDeclarationCompoundAssignments} (variable mapping in lines \ref{algTranslateCompoundDeclarationVarMappingStart}-\ref{algTranslateCompoundDeclarationVarMappingEnd} and slot translation in line \ref{algTranslateCompoundDeclarationTranslateSlots} along with the decision variables of the compound value). In both cases, Algorithm \ref{algTranslateAnnotationAssignments} is called. - -Algorithm \ref{algTranslateAnnotationAssignments} first builds up (incrementally) the set of effective assignments data $ea$ that is relevant for the actual assignment block $a$ (initially $ea=\emptySet$ for a top-level assignment block). -For a given assignment block $a$, the algorithm performs then the transformation of each individual assignment and collects the created constraints in $\otherConstraints$. If the type of the slot (if available the dynamic type of the value) is a compound, the algorithm performs the same transformation on all compound slots with respective accessors (either using the slot variable $d$ or the compound accessor $ca$ if given). Finally, the algorithm recursively processes contained assignment blocks. - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{assignment block $a$, variable $v$ effective assignment data $ea$, compound access $ca$} +We turn now to the translation of annotation assignment-blocks. In IVML, an assignment-block is used on top-level or within compounds to declare compound slots with an implicit assignment of a value to each declared annotation. Further, assignment-blocks can be nested and the assignments defined for the outer blocks must be applied also to the inner blocks. + +The translation of assignment-blocks on top-level is triggered by Algorithm \ref{algTranslateConstraints} in line \ref{algTranslateConstraintsTopLevelAnnotationAssignments}. The translation of assignment-blocks within compounds is caused by Algorithm \ref{algTranslateCompoundDeclaration} in line \ref{algTranslateCompoundDeclarationCompoundAssignments} (variable mapping in lines \ref{algTranslateCompoundDeclarationVarMappingStart}-\ref{algTranslateCompoundDeclarationVarMappingEnd} and slot translation in line \ref{algTranslateCompoundDeclarationTranslateSlots} along with the decision variables of the compound value). In both cases, Algorithm \ref{algTranslateAnnotationAssignments} is called. + +Algorithm \ref{algTranslateAnnotationAssignments} first builds up (incrementally) the set of effective assignments data $ea$ that is relevant for the actual assignment-block $a$ (initially $ea=\emptySet$ for a top-level assignment-block). +For a given assignment-block $a$, the algorithm performs then the transformation of each individual assignment and collects the created constraints in $\otherConstraints$. If the type of the slot (if available the dynamic type of the value) is a compound, the algorithm performs the same transformation on all compound slots with respective accessors (either using the slot variable $d$ or the compound accessor $ca$ if given). Finally, the algorithm recursively processes contained assignment-blocks. + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{assignment-block $a$, variable $v$ effective assignment data $ea$, compound access $ca$} \KwData{constraints $\otherConstraints$} @@ -825,5 +824,5 @@ + Refined compounds & 2.2.3.1 & \\ + Partial evaluation & 2.2.5.3 & \\ -+ Assignment block & 2.2.2 & \\ ++ Assignment-block & 2.2.2 & \\ Container type & 2.1.3.3 & complex value: Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateContainer} $\rightarrow$ Alg. \ref{algTranslateContainerDeclaration} \\ + Basic type & 2.1.3.1 & no specific constraints, cf. Section \ref{sectNotationOthers} \\