PinkRoccade is (nog steeds) van mening dat het opnemen van beëindigde relaties binnen het actueel deel van een Sh bericht niet gewenst en zelfs niet vereist is. Het is zelfs de vraag of de sleutelsynchornisatie vereist is (volgens ons niet). Ik zal onze argumentatie hiervoor in deze post nader toelichten.
In onze argumentatie reageren we tevens op de eerdere onderbouwing vanuit KING:
“De kern van het probleem is dat in het synchronisatiebericht op een gegeven moment een relatie voorkomt met de oudste gegevens in de historie van deze relatie. Je moet deze relatie identificeren in je eigen database en opnieuw gaan opbouwen met de kennisgevingen in het Sh01-bericht. Deze identificatie kan heel lastig zijn, als het oudste voorkomen van de relatie andere kerngegevens heeft dat het voorkomen van de relatie in actueel. Om dit probleem te ondervangen nemen we de nu geldige gegevens van de relaties op in het Sa01-bericht samen met een sleutelSynchronisatie die ook moet voorkomen in het oudste voorkomen. Op die manier is het identificatie probleem van de relaties opgelost. Op het moment dat je beëindigde relaties niet ook opneemt in het Sa01-bericht blijft het identificatieprobleem onopgelost voor de beëindigde relaties. Vandaar het voorschrift om die ook op te nemen in het Sa01-bericht binnen een Sh01-bericht.”
Argumentatie van PinkRoccade:
De argumentatie in paragraaf 5.4.1 en in het bovenstaande betoog van KING gaat ervan uit dat een relatie in het ontvangende systeem geïdentificeerd moet (kunnen) worden op basis van de oudste gegevens in het Sh bericht. Dit suggereert een implementatiewijze en het uitgangspunt van StUF is dat deze niet voorschrijft hoe de implementatie moet plaatsvinden. Het is overigens ook maar zeer de vraag of een relatie in de ontvangende applicatie altijd geïdentificeerd kan worden op basis van de actuele gegevens van deze relatie in een bericht. De reden voor het verzenden van een synchronisatie is namelijk veelal dat de gegevens binnen het zendende en ontvangende systeem niet consistent zijn en daarom gesynchroniseerd moeten worden.
In onze ogen zou een ontvanger van een Sh bericht eerst op basis van de oudste gegevens en de daarop volgende mutaties in dit bericht, het volledige object inclusief zijn historie (in het geheugen) kunnen opbouwen en vervolgens vergelijken met de gegevens in de eigen applicatie. Op dat moment beschikt de ontvangende applicatie over alle gegevens van het object en zijn relaties (dus zowel over de oudste gegevens, de chronologische mutaties maar ook over de meest actuele gegevens (inclusief die van de inmiddels beëindigde relaties!). Het actuele deel binnen het Sh bericht is hiervoor dus helemaal niet vereist. De reden om binnen een Sh bericht ook separaat de actuele gegevens op te nemen is dat een ontvanger die alleen actuele gegevens gebruikt, zijn gegevens kan synchroniseren zonder naar de historie (historische opbouw) te moeten kijken. Tevens ontslaat dit een zender van de verplichting om zowel een Sh als een Sa bericht te sturen indien er zowel afnemers zijn die historie bijhouden als afnemers die dit niet doen.
Er zijn daarnaast ook nog consequenties aan de beschreven werkwijze verbonden. Ten eerste wordt de standaard wederom een stukje complexer dan die nu al is en we willen juist naar een simpeler standaard. Daarnaast gaat het actuele deel binnen een Sh bericht nu afwijken van het Sa bericht tenzij je in het Sa bericht ook de beëindigde relaties opneemt. Dit is echter van geen toegevoegde waarde voor een ontvangende applicatie die geen historie vastlegt en het vereist zelfs dat een dergelijke applicatie rekening moet houden met deze relaties bij het synchroniseren van de eigen gegevens.
Ik hoop dat ik onze bezwaren hiermee voldoende heb toegelicht en dat KING het met ons eens is dat:
- het separaat opnemen van beëindigde relaties binnen de actuele gegevens is een Sh bericht niet nodig is omdat deze informatie afleidbaar is uit de overige gegevens in het bericht (oudste en mutaties).
- Het opnemen van de sleutelsynchornisatie niet vereist is omdat op basis van de gegevens (oudste en mutaties) in het Sh bericht de historie van het object opnieuw opgebouwd kan worden.
Het lijkt erop dat de voorgestelde wijzigingen van de StUF standaard ingegeven zijn door een partij (LV-WOZ?) die gekozen heeft voor een werkwijze waarbij niet eerst vanuit het Sh bericht de gehele historie van het object wordt opgebouwd om die later te vergelijken met de gegevens binnen de eigen registratie. Mogelijk wordt getracht tracht dit dynamisch te doen tijdens het verwerken van de losse mutaties in het Sh bericht. Aangezien de StUF standaard de implementatie niet mag voorschrijven en de informatie in het Sh bericht (zonder sleutelsynchornisatie en beëindigde relaties in actueel) voldoende is voor het verwerken ervan zijn we dus tegen de voorgestelde aanpassing enkel en alleen om een bepaalde specifieke implementatie mogelijk te maken.
Wij vernemen graag of KING onze argumentatie tegen de voorgenomen uitbreidingen begrijpt en kan onderschrijven. Los hiervan, willen we onze argumentatie inbrengen in de komende expertgroep (19-02-2014) waar de voorgestelde wijzigingen (errata onder agendapunt 4) op de agenda staan.
John Rooijakkers.
PinkRoccade Local Government
Linksom of rechtsom hebben de voorschriften in de StUF-standaard consequenties voor implementaties. Ook de derde alinea hierboven beschrijft een implementatie, die in mijn ogen aanmerkelijk complexer is dan de implementatie die wordt mogelijk gemaakt door het opnemen van sleutelSynchronisatie binnen Sh01/02 berichten. Ik vind het terecht dat we de standaard zo inrichten dat de implementatie van de gewenste functionaliteit zo simpel mogelijk is. Hierbij moet je natuurlijk afwegen hoe complex het maken van de berichten met sleutelSynchronisatie is. Andere partijen die communiceren met de LV WOZ zijn hierin al geslaagd. Ik snap niet zo goed waarom Pink hier nu tegen is.
Centric sluit zich aan bij de argumenten die door PinkRoccade worden aangedragen. Wij zijn er zeker geen voorstander van dat in de actuele situatie binnen het Sh-bericht ook de beëindigde relaties worden opgenomen. Dit druist in tegen een aantal principes die zijn gehanteerd bij het ontwerpen van de berichten. Ten eerste is er geen sprake meer van een actuele situatie en ten tweede vanwege het gebruik van Sh-berichten voor afnemers die geen historie ondersteunen (in plaats van Sh- én Sa-berichten te moeten sturen). Het opnemen van een sleutelSynchronisatie zien wij niet als groot bezwaar, hoewel ook wij de noodzaak niet helemaal zien. Hiervoor echter de inhoud van het eerste (actuele) voorkomen aan te passen is in onze ogen niet terecht en niet gewenst. Een optie zou kunnen zijn om de sleutelSynchronisatie op te nemen bij het eerste voorkomen van een object/relatie in het bericht, zodat de latere voorkomens compacter kunnen worden gemaakt en daarmee het bericht. Ook op basis van de oude gegevens van een relatie moet deze terug te vinden zijn in een database die de historie bij houdt. Waarom zou dat moeilijker zijn dan het vinden van de actuele situatie die beëindigd is? Zolang we geen overtuigend bewijs zien dat er echt niet zonder zo'n sleutel gewerkt kan worden, lijkt het ons verstandig terughoudend te blijven in het uitbreiden hiermee van de standaard. Volgens ons moeten de berichtstructuren zo eenduidig en eenvoudig mogelijk worden gehouden. Besluiten tot aanpassingen die één bepaalde implementatievorm ondersteunen moeten we niet lichtzinnig nemen. Of een implementatie eenvoudiger is dan een ander is vaak erg subjectief en hangt samen met factoren die in de specifieke discussie vaak niet worden meegenomen. Wij snappen niet dat Maarten voorstander is van een oplossing die de standaard complexer maakt, om één mogelijk eenvoudiger implementatievorm (mogelijk) eenvoudiger te maken.