In de bijeenkomst van de StUF Expertgroep van vanochtend (20-11-2013) werd de wens geuit om de synchronisatieberichten, naast de besproken wijzigingen, verder te verbeteren door de volgende twee extra aanpassingen door te voeren:
- Niet meer complete kennisgevingen hergebruiken in synchronisatieberichten maar alleen de body zonder stuurgegevens. Hierdoor worden de synchronisatieberichten een stuk compacter omdat de stuurgegevens niet meer onnodig worden gedupliceerd.
- Behalve binnen het element van het synchronisatiebericht gerelateerde entiteiten niet meer op te nemen. Via het attribuut StUF:sleutelSynchronisatie van de relaties kan de identificatie van de gerelateerde entiteit afgeleid worden.
Als je bezwaren hebt tegen deze deze twee extra aanpassingen, graag binnen twee weken reageren!
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR309.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Ik heb om een aantal redenen problemen met deze twee extra aanpassingen: 1. Deze fix is (min of meer) bedoeld om de bevindingen uit de implementatie van het Sectormodel-WOZ te verwerken in de StUF-standaard om zodoende ook het sectormodel weer in de StUF-familie op te nemen. Door nu meteen deze twee extra wijzigingen mee te nemen zal het Sectormodel-WOZ toch weer niet helemaal voldoen aan de StUF-Standaard tenzij er in januari ook meteen een release wordt gemaakt van dit sectormodel. Ik denk dat, gezien de intensieve pogingen die momenteel worden gedaan door de leveranciers om te voldoen aan de conformiteitstoets van de LV-WOZ, het niet wenselijk is om dan op 1 januari iedereen weer opnieuw aan het werk te zetten omdat er een nieuwe versie van het sectormodel nodig is. 2. Met het weglaten van de gerelateerde entiteit overal behalve in actueel heb ik een nog groter probleem. Dit gaat namelijk ervoor zorgen dat bij elk element in de oudste of een van de wijzigingen de software eerst moet gaan controleren of er in actueel een gerelateerde staat. Dit is bij het verwerken van 1 bericht misschien niet bezwaarlijk maar als je dit optelt voor zo'n 8.500.000 woz-objecten die via synchronisatieberichten worden gemeld bij het aansluiten van alle gemeenten tellen al deze extra acties wel degelijk op. Ik vind dat het bij het toevoegen van een relatie (verwerkingsoort='T' en verwerkingsoort 'R' bij de wordt-situatie) de gerelateerde moet worden opgenomen. Bij alle andere plaatsen (de oude-situaties in wijzigen ed.) zouden deze elementen op den duur wel weggelaten kunnen worden maar gezien opmerking 1 niet in de januari release. 3. Het weglaten van de stuurgegevens heeft een geheel ander probleem. Indien een (toekomstig) sectormodel niet werkt met een tijdstipRegistratie dan zou (volgens mij) het tijdstipBericht uit de stuurgegevens van een sub-bericht van het synchronisatie nog wel eens belangrijk kunnen worden teneinde de juiste historische voorkomen in het ontvangende systeem te bepalen.
Vanuit Sectormodel WOZ wil ook graag een reactie op drie niveaus geven. 1. Inhoudelijk denk ik dat niet dat het eerste voorstel tot grote problemen leidt. Ik vraag mij wel af of het tweede voorstel in alle situatie consistent werkt. De systematiek gaat er volgens mij ten onrechte vanuit dat alle gerelateerde die in "oudste" of "wijziging" worden opgevoerd ook voorkomen in actueel. Naast de bezwaren die Mark verder schetst voor de verwerking van de eventuele synchronisatieberichten zonder deze gerelateerden, vraag ik mij ook af of het weglaten van deze gerelateerde voor het maken van de synchronisatieberichten een voordeel is. Immers het lijkt minder goed mogelijk om functionaliteit voor vervaardigen mutatieberichten te hergebruiken voor het maken van de synchronisatieberichten. Ik hoor dus ook graag de visie van partijen die vooral deze synchronisatieberichten gaan maken. 2. De vervolgvraag is of deze wijziging gezien kan worden als een fix in een patch of dat dit uitsluitend kan in een release. Ik heb sterk het idee dat dit een zodanig ingrijpende wijziging betreft, dat het niet passend is om dit in een patch op te nemen. Immers deze wijziging heeft zeer ingrijpende gevolgen voor de berichten en er zijn inderdaad rond de LV WOZ nu diverse applicaties waarin één en ander is geïmplementeerd. Maar ook op andere punten zijn er volgens mij wel implementaties van synchronisatieberichten (wellicht niet met volledige formele en materiële historie) die door deze wijziging aangepast moeten worden. Afhankelijk van de inhoudelijke discussie zou ik er sterk voor willen pleiten deze wijziging, als deze inhoudelijk wenselijk is, uitsluitend mee te nemen in een volgende release en niet in een patch door te voeren. 3. Aansluiten Sectormodel WOZ op deze standaard. Voor de realisatie van het koppelvlak met de LV WOZ zijn vooruitlopend op een aantal discussies rond de StUF standaard enkele keuzes gemaakt en vastgelegd in de xsd-schema's die onderdeel uitmaken van de koppelvlakspecificaties voor de LV WOZ. Diverse partijen zijn nu druk bezig hun conformiteitsdiploma te halen voor dit koppelvlak. Wij zullen de xsd-schema's voor dit koppelvlak zo lang mogelijk stabiel houden. De genoemde wijziging zal voor het koppelvlak met de LV WOZ in ieder geval een nieuwe release betekenen die dan ook gedurende tenminste een jaar zal moeten draaien naast de oude release. In het huidige implementatietraject achten wij dat niet verstandig. Wij zullen deze wijziging, wanneer die als patch wordt doorgevoerd, daarom vooralsnog niet overnemen in de koppelvlakspecificaties voor de LV WOZ en daarmee in het Sectormodel WOZ. Dat is jammer, omdat daardoor (weer) een verschil ontstaat tussen de standaard en het gebruik van de standaard binnen Sectormodel WOZ, maar gezien de grote invloed op bestaande applicaties hebben wij geen andere keus. Hiermee hoop ik duidelijk gemaakt te hebben dat wij significante bezwaren hebben tegen deze voorstellen.
Ook ik ben van mening dat we in een bugfix geen functionaliteit moeten willen verbeteren die door partijen reeds geïmplementeerd is. Dit kan beter gedaan worden in een nieuwe release met een ordentelijk migratietraject. De beide versies mogen dan een tijdje naast elkaar bestaan. Dit is met een fix niet het geval.
Tijdens de StUF Expertgroep van 21 mei 2014 is besloten dit issue naar een RFC om te zetten. Het is opgevoerd als RFC0333.
Tijdens de StUF Expertgroep van 18-2-2015 heeft een deel van de aanwezigen aangegeven dit als laaghangend fruit te zien. Nu moeten de stuurgegevens steeds herhaald worden. Ook in samengestelde berichten zou dit gelden maar daarmee is niet iedereen het eens. Dat zou immers betekenen dat je geen berichten voor verschillende entiteiten meer zou kunnen opnemen in een samengesteld bericht. Daar lijkt echter wel een oplossing voor te zijn.
Tijdens de StUF Expertgroep van 20-5-2015 is besloten dat dit RFC wordt meegenomen in de komende versie van StUF. Volgens Maarten van den Broek is het niet zo ingewikkeld.
Tijdens de StUF Expertgroep van 21 oktober 2015 is dit RFC goedgekeurd.
N.a.v. goedkeuring van de wijzigingen in de StUF 3.02 specificatie in de StUF Expertgroep van 21 december 2016 is de status van dit RFC op 'Uitwerking goedgekeurd' gezet.