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 Ebenen 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.

11.
In omds3_ON2_Antrag_Kfz.xsd ist das Element CreateOfferKfzResponse_Type inkonsistent zu den anderen Typen
CreateApplicationKfzResponse_Type, CalculateKfzResponse_Type und SubmitApplicationKfzResponse_Type. Es sollte
angeglichen werden.

12.
In den neueren BOA Sparten (Unfall, Leben, Kranken, Rechtsschutz) definieren wir nicht eigens benannte ComplexTypes
für die Aufrufe, sondern gleich Elemente. Dies reduziert die Anzahl der Objekte und ist möglich, weil
es ohnehin nur jeweils ein Element gibt. Kfz und Sach-Privat sollten dahingehend umgestellt werden.

13.
Das Element "VersPersonenRefLfnr" in ProduktMitVp_Type sollte umbenannt werden auf "VersPersonRefLfnr",
da immer genau eine Person referenziert wird.

14.
Personen und Risikoobjekte werden über Lfnr im Antrag referenziert. Dies könnte eventuell vereinfacht werden,
in dem man einfach Attribute PersonenId und RisikoId oder RisikoObjektId vom Typ String verwendet. Dann könnten
auch die originären Ids der Objekte Verwendung finden. Allerdings müssen neue Personen und Risikoobjekte
in einem Antrag nicht unbedingt eine Id bei der VU haben.

15.
Vorversicherungen sind aus Rücksichtnahme auf den Bestand in Kfz unnötig kompliziert geworden, sollte vereinfacht
werden.

16.
Die Spez-Objekte der Schritte im Antragsprozess sollten voneinander abgeleitet werden.