RFC: Het wijzigen van het update element in het vrije bericht

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

6 reacties / 0 nieuw
Maarten van den...
RFC: Het wijzigen van het update element in het vrije bericht

Probleem

Het vrije bericht kent een update element dat nul of meer keren mag voorkomen. Omdat er precies één update-element is in het schema, kan er slechts één complexType voor gedefinieerd worden. Als in het vrije bericht wijzigingen moeten worden doorgevoerd op verschillende objecttypen, dan dienen deze als een choice in het complexType voor het update element te worden opgenomen en dient het update element een kardinaliteit groter dan één te krijgen. Deze constructie maakt het onmogelijk om voor te schrijven dat de wijzigingen in een bepaalde volgorde moeten worden doorgevoerd.

Voorgestelde oplossing

Maak van een update-element een groepselement dat één of meer keren een sequence bevat van een parameters-element (voor de parametersKennisgeving) en een object element.

Maarten van den...

De voorgestelde oplossing blijkt niet te werken, omdat in die sequence het verplichte element object dan meerdere keren voorkomt met verschillende typen.

Een alternatief voorstel is dan om dit probleem op te lossen door in plaats van een element met voorgeschreven naam 'update' een element met een vrije naam te gebruiken met een attribute StUF:functie. Wanneer het attribute StUF:functie de waarde "update", dan gaat het om een element dat als inhoud de inhoud van het huidige update element dient te hebben.

Op deze manier kunnen eenvoudig in een vrij bericht updates van verschillende objecttypen worden opgenomen. Omdat dit met de huidige specificatie onmogelijk is en dit nooit de bedoeling is geweest, wil ik voorstellen deze nieuwe specificatie als een erratum op te nemen in StUF0301. De huidige constructie mag gebruikt worden, maar wordt wel deprecated en zal in een volgende versie van de standaard vervangen worden door de nu voorgestelde oplossing.

Hetzelfde speelt overigens bij het vraag-element. Ook daar lijkt het verstandig om de element-naam vrij te laten zijn en de functie te specificeren door middel van attribute StUF:functie="vraag".

Ruud Kathmann

Maarten, 

Uit de exercitie de we gedaan hebben met het formuleren van "Dienstberichten" om te communiceren met de LV WOZ, lijkt jouw oplossing goed te werken. Het maakt het definiëren van samenhangende mutatieberichten (gebeurtenissen) flexibel mogelijk en je kan ook de nodige eisen aan het bericht in het schema afdwingen.

Dit lijkt dus inderdaad een goed stap in het daadwerkelijk omarmen van gebeurtenisgericht werken met StUF.

Inderdaad ook graag in StUF 03.01 opnemen als "erratum". Dan kunnen wij namelijk ook op korte termijn deze werkwijze toepassen in de definitie van het koppelvlak LV WOZ.

John Rooijakkers

Beste Maarten,

Ik vind het erg lastig om het voorstel te beoordelen zonder concrete voorbeelden. Zo op het eerste gezicht kan ik geen bezwaren opwerpen, maar heb ik ook niet het idee dat ik het voldoende overzie. Wellicht kun je in deze post of tijdens de StUF EG een conreet voorbeeld van een probleem (bv in het sectormodel WOZ) aandragen en de oplossing van het issue conform je voorstel.

Groeten, John Rooijakkers

Eric Tamminga

Beste Maarten,

Het sectormodel StUF-LVO 3.11 is gebouwd op StUF3.01 patch 9, StUF-BG0310 patch 10 en StUF-ZKN0310 patch 10. StUF-LVO 3.11 maakt gebruik van de 'deprecated' update-element voor wat betreft 'Di01' en 'Du01' vrije kennisgevingsberichten.

Jij schrijft in je post van 15-2-2011 15:18:49: "De huidige constructie mag gebruikt worden, maar wordt wel deprecated en zal in een volgende versie van de standaard vervangen worden door de nu voorgestelde oplossing."

Anders dan in een paar expert groep verslagen kan ik erg moeilijk hier meer informatie over vinden.

Kun jij aangeven in hoeverre jouw opmerking nog steeds geldig is? Anders gevraagd kan StUF-LVO 3.12 nog steeds gebaseerd blijven op de opbouw van StUF-LVO 3.11, dat is gebruik blijven maken van de 'depracted' constructie?

Met vriendelijke groeten,
Eric Tamminga

Maarten van den...

Het attribute StUF:functie is in de vorm van een erratum doorgevoerd in de standaard. Er wordt bij mijn weten nergens gerept over het deprecated zijn van de olrspronkelijke constructie met een element update in een vrij bericht. Een nieuwe versie van de lvo zou ik daarom maar baseren op de nieuwe definitoes. Je kunt volstaan met toevoegen van het attribute StUF:functie in de update-elementen.