diff --git a/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex b/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex
index e10992ac..007baf31 100644
--- a/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex
+++ b/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex
@@ -199,20 +199,24 @@
Hier gibt es zwei Lösungsmöglichkeiten:
\begin{itemize}
\item Der Client zeigt die Daten einem Menschen, welcher mit heterogene textliche Informationen etwaiger
- Fehlermeldungen interpretieren kann und die Daten in die passende Form bringt.
+ Fehlermeldungen umgehen kann und die Daten in die passende Form bringt.
\item Das Objektmodell wird so erweitert, dass es statt vieler individueller und vom Client unberücksichtigter
Regeln einige wenige vom Client zu berücksichtigende Regeln gibt. Der Client wird so erstellt,
dass er der formalen Unterstützung folgt. Damit dieser Weg effizient verfolgt werden kann, muss die Unterstützung
von allen Serviceprovidern gleich geboten werden, d.h. sie muss in der Norm verbindlich vorgeschrieben werden.
Diese Unterstützung muss abrufbar sein, ohne die Änderung gleich auszulösen.
+ Welche Unterstützung für welches inhaltliche Thema angemessen ist, kann unterschiedlich ausfallen. Die
+ Unterstützung, die für das Ausfüllen von Kfz-Daten hilfreich ist, ist vermutlich anders als die
+ Unterstützung bei der Konfiguration eines Deckungsbaums. Es mag aber auch themenübergreifend einheitliche
+ Unterstützungselemente geben, z.B. die Angabe von Wertebereichen für Parameter.
\end{itemize}
Bei beiden Lösungswegen ist ein zusätzlicher Service erforderlich, um das Objektmodell zu validieren oder
auszuführen.
\end{itemize}
- \subsubsection{Modell am Server stateful vs. stateless}
- Wenn zwei Services stellt sich die Frage, ob diese stateless umgesetzt werden sollen oder stateful, das Modell der
- Änderung also am Server verwaltet werden soll.
+ \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).
\paragraph{Vorteile stateful}
\begin{itemize}
\item Bei einem invaliden Request vom Client, kann das letzte gültige Modell am Server erhalten bleiben.
diff --git a/OMDSServiceDefinition/src/main/resources/def/r2025_27/omds3_ON3_Vertrag.xsd b/OMDSServiceDefinition/src/main/resources/def/r2025_27/omds3_ON3_Vertrag.xsd
index dcbb1875..79ccc046 100644
--- a/OMDSServiceDefinition/src/main/resources/def/r2025_27/omds3_ON3_Vertrag.xsd
+++ b/OMDSServiceDefinition/src/main/resources/def/r2025_27/omds3_ON3_Vertrag.xsd
@@ -3,9 +3,14 @@
-
-
-
+
+
+ ===========================================================
+ | Vertragsänderungen |
+ ===========================================================
+
+
+
Requests-Type zur Anfrage von Änderungsmöglichkeiten für einen Vertrag
@@ -406,112 +411,4 @@
-
-
-
- Ein abstrakter Deckungsbaustein, von dem die konkreten abgeleitet werden.
-
-
-
-
- Referenz auf das Produkt und etwaige Auswahlmöglichkeiten. Wenn es keine Wahlmöglichkeiten gibt, muss dieses Element nicht vorhanden sein.
-
-
-
-
- Im Response: Meldungen zu Elementen in diesem Produktbaustein
-
-
-
-
- Eines oder mehrere Attribute.
-
-
-
-
- Vorhandene oder optional einschließbare Unterbausteine.
-
-
-
-
-
-
- Deckungsbaustein der Ebene 1 "Verkaufsprodukt".
-
-
-
-
-
-
-
-
-
- Deckungsbaustein der Ebene 2 und tiefer.
-
-
-
-
-
-
- Ob dieser Produktbaustein eingeschlossen ist oder nicht
-
-
-
-
- Ob der im Response vorgebene Einschluss änderbar ist. Optional
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-