productmodel/OMDSServiceDefinition/src/main/resources/Backlog.txt

B A C K L O G
=============

Änderungen, die aus Gründen der Abwärtskompatibilität bisher nicht vorgenommen wurden,
aber mit einer Version 2 durchgeführt werden sollten.

1.
Von den Ebenenen der Produktmodellierung gibt es einfache Typen und "generische" Typen,
die optional noch Metainformationen aufnehmen können. Die einfachen Typen werden in Kfz verwendet.
Kfz sollte auch die generischen Typen verwenden, die einfachen würden dann komplett entfallen.

2.
omds3ServiceTypes und omds3CommonServiceTypes sind gegenseitig voneinander abhängig.
Die Abhängigkeit sollte nur omds3ServiceTypes --> omds3CommonServiceTypes sein.
Dazu müsste ost:PolicyPartnerRole verschoben werden nach omds3CommonServiceTypes.
Das wäre eine nicht-abwärtskompatible Änderung.

3.
In omds3CommonServiceTypes.xsd sollte <xsd:complexType name="ServiceFault"> umbenannt werden
zu "ServiceFault_Type" und das zugehörige Element "serviceFault" sollte "ServiceFault" heissen.

4.
Wir haben in Kfz ein Element für Vinkulierung definiert und dann im Kontext für Leben das Thema
Sicherstellungen (inkl. Vinkulierung) nochmals allgemeiner gelöst. Kfz sollte auch auf die neue
Lösung umgestellt werden.

5.
Sach-privat kann derzeit kein Unfall als gleichberechtigtes Produkt aufnehmen, Unfall muesste
als Zusatzprodukt aufgenommen werden. Das ist technisch unproblematisch, fachlich wäre Unfall
aber eigentlich gleichberechtigt zu Haushalt oder Eigenheim zu sehen. Der Typ des Produkts im
Verkaufsprodukt müsste dafür aber weiter gefasst werden, also nicht ProduktSachPrivat_Type.

6.
Für die Methoden Calculate, CreateOffer, CreateApplication und SubmitApplication haben wir
immer einen ComplexType definiert und ein Element, welches von diesem Typ ist. Dies könnte man
auch kompakter in einem Element mit einem anonymen inneren komplexen Typ machen. Dies hätte den
Vorteil, dass unter Java-cxf auch ein (@XmlRootElement(name = "CalculateSachPrivatRequest")-Tag) generiert
wird, der wiederum die Verarbeitung eines Requests vereinfacht.

7.
Für die Berechnungsvariante gibt es die Einstufung einfach-mittel-top. Was ist, wenn eine VU hier
eine andere Anzahl von Varianten anbieten möchte? Wurde bisher nicht tiefer diskutiert.

8.
Regex Variante ist bislang nicht definiert.

9.
Die Namespaces beinhalten die Versionnummer zu der das betreffende XSD erstmals definiert wurde.
Diese Information bringt keinen Mehrwert und sollte mit einer einheitlichen Hauptversionsnummer,
z.B. "2" ersetzt werden. Zudem sollte dem "urn:" eine Namespace-Id folgen, eventuell wäre es
besser gleich eine URL zu wählen, die sich auf eine Adresse im Internet auflösen lässt, wo zusätzliche
Informationen bereitgestellt werden.

10.
Die Liste Dateianhhänge soll aus SubmitApplicationRequest_Type (und möglichen weiteren Stellen entfernt werden,
es soll nur noch ProzessDokumente verwendet werden.