In paragraaf 2.6 Het platslaan van gegevens en historie van versie 1.07 van het document keuzenVerStUFfing RSGB.pdf (zie patch 15 dd 20130401 van StUF BG 03.10) staat onderstaande tekst:
2.6 Het platslaan van gegevens en historie
In bg0310 worden op een aantal plaatsen de gegevens van een gerelateerde opgenomen in de StUF-entiteit vanwaaruit de relatie ligt.
Voor de platgeslagen gegevens geldt dat historie niet relevant is, tenzij de platgeslagen zijn opgenomen in het historieMaterieel- of het historieFormeel-element van de entiteit waarin de gegevens zijn platgeslagen.
Voor het al dan niet relevant zijn van historie wordt dus niet uitgegaan van de specificatie in het entiteittype vanwaaruit de gegevens zijn platgeslagen, maar van de specificatie in het entiteittype waarin de gegevens zijn platgeslagen.
Platgeslagen gegevens buiten het historieMaterieel- of het historieFormeel-element moeten gewoon behandeld worden alsof ze elementen zijn van het object waarin ze zijn platgeslagen.
Wijzigingen in gegevens van deze platgeslagen relaties moeten leiden tot kennisgevingen van alle betrokken objecten.
einde citaat.
De eerste twee zinnen zijn mij redelijk duidelijk.
De derde zin ("Voor het al dan niet relevant zijn..") levert mij ook geen problemen op, al is deze zin een toelichting en niet normatief.
De vierde zin ("Platgeslagen gegevens buiten het historieMaterieel- of het historieFormeel-element moeten...") is mij niet duidelijk. Wat wordt bedoeld met "buiten"? Wat wordt bedoeld met "gewoon". Wat houdt "behandelen" in?
De laatste en vijfde zin ("Wijzigingen in gegevens...") vind ik helemaal verwarrend. Er worden twee nieuwe termen geïntroduceerd ("gegevens van deze platgeslagen relaties" en "betrokken objecten") en mij is niet duidelijk waar deze zin op slaat (op zin 4 of de hele paragraaf).
Ik neem aan dat er vier mogelijkheden zijn:
a) een platgeslagen gegeven is opgenomen in het element historieMaterieel
b) een platgeslagen gegeven is opgenomen in het element historieFormeel
c) een platgeslagen gegeven is opgenomen in zowel het element historieMaterieel als het element historieFormeel
d) een platgeslagen gegeven is niet opgenomen in het element historieMaterieel en ook niet in het element historieFormeel.
Ik neem aan dat de vierde zin gaat over situatie d).
Vervolgens neem ik aan dat met "gewoon behandelen" wordt bedoeld dat er geen historie moet worden opgebouwd.
Ten derde neem ik aan dat de laatste zin slaat op de hele paragraaf.
Als ik tenslotte de onduidelijkheid over "behandelen" in de vierde zin wegneem door aanvullende informatie in de laatste zin op te nemen en de onderdelen van het geheel (normatieve tekst, toelichting en verwerkuing) door middel van opmaak in paragrafen expliciet zichtbaar maak, dan krijg ik het volgende voorstel:
2.6 Het platslaan van gegevens en historie
In bg0310 worden op een aantal plaatsen de gegevens van een gerelateerde opgenomen in de StUF-entiteit vanwaaruit de relatie ligt. Voor de platgeslagen gegevens geldt dat historie niet relevant is, tenzij de platgeslagen gegevens zijn opgenomen in het historieMaterieel- of het historieFormeel-element van de entiteit waarin de gegevens zijn platgeslagen.
Voor het al dan niet relevant zijn van historie wordt dus niet uitgegaan van de specificatie in het entiteittype vanwaaruit de gegevens zijn platgeslagen, maar van de specificatie in het entiteittype waarin de gegevens zijn platgeslagen. Wijzigingen in platgeslagen gegevens, die niet zijn opgenomen in het element historieMaterieel en ook niet in het element historieFormeel, leiden in dat geval dus niet tot het opbouwen van historie.
Als een gegeven G van een object X in het RSGB, dat optreedt als een gerelateerde van een object Y in het RSGB, wijzigt, dan moet dit leiden tot een kennisgevingbericht of een synchronisatiebericht van zowel het object X' (het in bg0310 versStUFde object X uit het RSGB) als een kennisgevingbericht of een synchronisatiebericht voor ieder object Y' (het in bg0310 versStUFde object Y uit het RSGB) waarin het gegeven G is platgeslagen. In de specificatie van de StUF onderlaag staat gespecificeerd of er een kennisgevingbericht of een synchronisatiebericht moet worden verstuurd en wat de waarde van de parameter mutatiesoort moet zijn.
Dit erratum is opgevoerd in de onderhoudsverzoeken als ERR279.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Helemaal eens met Han dat sectie 2.6 van 'keuzenVerStUFfing RSGB.pdf' niet makkelijk te lezen is. Daarom heb ik deze sectie geheel herschreven en aangevuld met een voorbeeld inclusief plaatjes (zie bijlage: keuzenVerStUFfing RSGB_ sectie_2_6.pdf). Dit is dan meteen de uitwerking van erratum ERR279 dat voor de aankomende StUF Expertgroep op de agenda staat. Mijn suggestie is om een deel van deze tekst ook op te nemen in de Best Practices zodat deze werkwijze ook in nieuwe sectormodellen wordt toegepast.
Bijlage
Er is ook nog aandacht nodig voor de implicaties van het platslaan gegevens voor de historie, want platgeslagen gegevens zijn niet van elkaar onafhankelijk en dat heeft hinderlijke gevolgen. Het lijkt het beste om voor te schrijven dat er voor platgeslagen gegevens geen historie mag worden gedefinieerd binnen de entiteit waarin de platgeslagen gegevens voorkomen. Het lijkt me verstandig dit ook bij dit erratum mee te nemen.
Ik ben het eens met Maarten dat platgeslagen elementen hinderlijke gevolgen heeft voor het opbouwen van historie. Ik vermoed dat de intentie van Maarten's opmerking "Het lijkt het beste om voor te schrijven dat er voor platgeslagen gegevens geen historie mag worden gedefinieerd binnen de entiteit waarin de platgeslagen gegevens voorkomen. Het lijkt me verstandig dit ook bij dit erratum mee te nemen." is om te voorkomen dat historie moet worden opgebouwd over platgeslagen gegevens door aan te bevelen platgeslagen elementen niet op te nemen in historieMateriaal of historieFormeel. Maar feit is dat dit op vele plekken binnen BG, BagBerichtencatalogus en sectormodelWoz al het geval is. Dus, wat wil je daar dan mee doen? Mijn opmerking was dat de spec niet duidelijk was. Het voorstel van Henri Korver lijkt me duidelijk. Ik ben benieuwd wat de gevolgen van Maartens opmerking zijn op het voorstel van Henri.
Ik ben het eens met Han dat we Maartens opmerking niet zomaar als erratum kunnen verwerken in het huidige bg0310. Het lijkt meer op een RFC, tenzij iedereen het er over eens is dat dit een fout is die asap hersteld moet worden. In dat geval betreft het een reparatie (erratum / bug fix) die niet backwards compatible is. Wel kunnen we Maartens opmerking verwerken in de StUF Best Practices zodat in nieuwe sectormodellen niet dezelfde "fout" wordt gemaakt.
Ten behoeve van de bestaande sectormodellen lijkt er geen behoefte aan het wijzigen van de huidige implementaties, omdat de laatste post alweer dateert van bijna 2,5 jaar geleden. Doorvoeren als een erratum lijkt derhalve niet zinnig.
Het is wel verstandig om de door Han en Henri voorgestelde verbeteringen mee te nemen in de nieuwe onderlaag en het nieuwe verStUFfingsdocument voor het RSGB, omdat binnen Adresseerbare Objectaanduiding de relatie naar Openbare Ruimte (inclusief de relatie van Openbare Ruimte naar Woonplaats) nog wordt platgeslagen.
Dit erratum kan dus worden omgezet in een RFC voor de onderlaag en voor bg0310.
Wij zijn wel benieuwd wat dit erratum betekent voor bijvoorbeeld het adres bij een persoon. Wanneer het woonadres van een persoon platgeslagen is, kan een wijziging van de woonplaatsnaam historisch niet teruggevonden worden. De vraag is of dit de bedoeling is.
Is het gezien deze discussie niet beter om platslaan helemaal uit te bannen.
Tijdens de StUF Expertgroep van 15 februari 2017 is dit Erratum afgevoerd.