In zkn0310_msg_mutatie.xsd worden berichten als een zakLk01 gedefinieerd als element van een bepaald type. Hiervoor is dan een bepaald complexType gedefinieerd, in dit geval een ZAK-Lk01 complexType.
In zkn0310_msg_vraagAntwoord.xsd wordenn berichten "hard" gedefinieerd, als element met daarbinnen een complexType. Als voorbeeld noem ik een edcLa01.
Het complexType in de laatste constructie is niet te hergebruiken in andere berichten. Voor koppelvlakken is het handiger wanneer bijvoorbeeld een ZAK-Lk01 complexType gerestrict kan worden in een aangescherpt bericht. Bij een "intern" complexType moet het bericht gekopieerd worden, wat natuurlijk kan maar dan is minder duidelijk dat het om een aangescherpt StUF-ZKN bericht gaat.
Met het oog op de ontwikkelingen om in de toekomst in de koppelvlakken aangescherpte berichten te gebruiken zou het waardevol zijn wanneer ook de berichten met een "intern" complexType gerefactored zouden worden naar een "extern" complexType.
Dit RFC is opgevoerd in de onderhoudsverzoeken als ONV0420.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Om een idee te krijgen van de omvang van de bewerking, die op zich niet zo ingewikkeld is, er vanuit gaand dat we deze bewerking op alle sectormodellen uitvoeren die in beheer zijn bij KING (StUF-BG 3.10, StUF-ZKN 3.10 en StUF-ZTC 3.10), heb ik het aantal aan te maken complexTypes en dus ook aan te passen berichten hieronder even per sectormodel in een tabel geplaatst. Het gaat daarbij om Sa03, Sa04, Sh01, Sh02, Sh03, Sh04, La01, La02, La03, La04, La05, La06, La07, La08, La09, La10, Lv01, Lv02, Lv03, Lv04, Lv05, Lv06, Lv07, Lv08, Lv09 en Lv10.
De volledige inventarisatie is bijgevoegd.
Indien we alles om willen zetten betekent het dat we 1260 complexTypes moeten aanmaken en daarnaar in evenzoveel berichten moeten gaan verwijzen. Natuurlijk kunnen we besluiten slechts bepaalde type berichten om te zetten en kunnen de berichten in het sectormodel StUF-ZTC 3.10 weer automatisch gegenereerd worden.
De bewerking geeft overigens geen backwards compatibiliteits problemen.
Bijlage
Tijdens de StUF Expertgroep van 20 april 2016 heeft Maarten voorgesteld om naar aanleiding van dit issue in de best practices te beschrijven dat we in de koppelvlakschema’s helemaal geen globale complexTypes gebruiken. Hij ziet namelijk grote voordelen voor code-generatie. Vanuit onderhoudsoogpunt was hij het echter helemaal eens met Michiel. Het maakte hem echter niet uit hoe KING het onderhoud inricht en hij was van mening dat zulke issue dan ook niet in de StUF Expertgroep besproken hoeven te worden.
Henri benadrukte dat het genereren van schema’s zonder complexTypes nog helemaal geen fact is. Ik vroeg me overigens nog wel af of het niet gebruiken van complexTypes in de koppelvlakschema's wel zo handig is. Op mijn vraag of dit niet vervelend is aangezien in dat geval bij code-generatie geen hergebruik gemaakt kan worden van de code en er dus veel redundant code gegenereerd wordt gaven enkele aanwezigen aan dat dit naar hun mening helemaal geen probleem is. Wouter gaf aan dat het gebruik van global complexTypes ook tot extra code leidt.
De StUF Expertgroep heeft uiteindelijk besloten om het onderhoudsverzoek af te wijzen.