KapDionOS/productmodel
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Restore Mtom

Browse Source
This commit is contained in:
Jens Bühring
2020-07-10 04:57:40 +02:00
parent 99d1774709
commit b15f5d25cc
4 changed files with 40 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
OMDSServiceDefinition/src/main/resources/Backlog.txt
View File

@@ -4,15 +4,42 @@ 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.
2.
3.
In omds3CommonServiceTypes.xsd sollte <xsd:complexType name="ServiceFault"> umbenannt werden
zu "ServiceFault_Type" und das zugehörige Element "serviceFault" sollte "ServiceFault" heissen.
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.