\begin{frame}
 \frametitle{Organisation en espace de nommage}
 \begin{itemize}
  \item dans \emph{tiramisu} l'accent est mis sur l'organisation arborescente des données ;
  \item la validation des options de configuration se fait par l'appartenance aux groupes (families, master/slaves \dots) ;
  \item l'organisation en groupes est unifiée par l'espace de nommage ;
  \item la lisibilité de l'API excellente, contrairement à \emph{Creole}
  \item \texttt{eole-report/D03ReglesEtats.pdf}
  \item lisibilité d'une config : \texttt{tiramisu/report/build/index.html} rapport html d'une config

 \end{itemize}

\end{frame}

\begin{frame}
 \frametitle{Etats de la configuration}
 \begin{itemize}
  \item système d'états de la configuration par droits d'accès
  \item \texttt{read write}, \texttt{read only};
  \item correspond à \texttt{freeze}, \texttt{hidden}, \texttt{disabled} \dots ;
  \item \texttt{doc/status.html}
  \item \texttt{eole-report/D03ReglesEtats.pdf}
 \end{itemize}

\end{frame}

\begin{frame}
 \frametitle{hidden if in, hidden if not in}
 \begin{itemize}
 \item les hidden if in, disabled if, \dots sont généralisés
 \item dans tiramisu, ce sont des pré-requis sur une (des) variables
 \item \texttt{eole-report/D03ReglesEtats.pdf}
 \item \texttt{doc/consistency.html}
 \end{itemize}

\end{frame}

\begin{frame}
 \frametitle{compatibilité Créole : ce qui reste à faire}
 \begin{itemize}
\item tous les options spéciales sont implémentées (auto, fill, obligatoire, \dots)
\item tous les états sont implémentés (hidden, disabled, mode (normal/expert), \dots)
\item reste la librairie des fonctions pour les variables automatiques
\item les "valprec" (valeur précédentes) 
\item fixer les comportement des hides (sous-groupes récursifs, \dots)
\item validations master/slaves, validations globales (au regard de la configuration entière) éventuellement
\end{itemize}

\end{frame}