Ergänzen von Bezügen zu Reiko Heckels "Graph Transformation" Artikel

OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex

@@ -183,6 +183,17 @@
     \end{itemize}
 
     \subsubsection{Normierungsgrad des Laufzeitverhaltens}
+
+    Die Daten für eine Änderung können in verschiedenen Formen angegeben werden. Heckel nennt dies \textit{Szenario} und
+    die Repräsentation im Graph nennt er \textit{instance graph}.
+    Die Form, die die Daten für die Übertragung annehmen können werden bei uns über das XSD vorgegeben,
+    das XSD definiert den \textit{Type-Graph}. Die Typen im XSD (\texttt{ComplexType} und \texttt{SimpleType})
+    sind die \textit{Concepts} bei Heckel.
+
+    Der instance graph kann Schrittweise verändert werden, sein \textit{state} wird transformiert. Die möglichen oder
+    zulässigen Änderungen des Zustands, folgen dabei bestimmten Regeln, bei Heckel werden diese als \textit{rules} bezeichnet.
+
+
     \begin{itemize}
         \item Datenobjekte mit individuellem Laufzeitverhalten: Bei diesen Objekten wird zwar die Struktur des
         Objekts in der Norm oder durch den Serviceprovider mittels Xml-Schema-Definition (XSD) festgelegt, die
@@ -215,8 +226,8 @@
     \end{itemize}
 
     \subsubsection{Modell am Server?}
-    Bei Änderungen mit zwei Services stellt sich die Frage, ob diese beiden Services stateless umgesetzt werden sollen
-    oder ob das Modell der Änderung am Server verwaltet werden soll (stateful).
+    Bei Änderungen mit zwei Services stellt sich die Frage, ob diese beiden Services voneinander vollkommen
+    unabhängig sein sollen (stateless) oder ob das Modell der Änderung am Server verwaltet werden soll (stateful).
     \paragraph{Vorteile stateful}
     \begin{itemize}
         \item Bei einem invaliden Request vom Client, kann das letzte gültige Modell am Server erhalten bleiben.