Het verzoek is om de samengestelde kennisgeving af te schaffen, omdat exact dezelfde functionaliteit op een simpeler manier wordt geboden in vrije berichten. Immers daar hoeft alleen de body van de enkelvoudige kennisgevingen te worden opgenomen en hoeven de stuurgegevens niet te worden gedupliceerd. Het maakt bovendien de specificatie van het element functie in de stuurgegevens eenduidiger, want die is dan alleen nog nodig voor vrije berichten.
Het voorstel is om de samengestelde kennisgeving in de aankomende stuf0302 versie te verwijderen.
het samengestelde bericht wordt al toegepast bij gemeenten door BAG leveranciers, zoals vastgesteld in de BAG berichtcatalogus. Is daar ook al rekening mee gehouden?
Bij het opstellen van de Berichtcatalogus BAG (eerst vastgesteld onder de naam koppelvlak BAG-WOZ) is al de discussie geweest of we gebruik zouden maken van samengestelde kennisgevingen of juist van vrije berichten.
Op dat moment is gekozen voor de samengestelde berichten. De belangrijkste argumenten daarbij waren:
- er is nog weinig ervaring met de vrije berichten;
- bij gebruik samengestelde berichten kan bestaande functionaliteit voor kennisgevingsberichten deels worden hergebruikt.
Op dit moment is er veel meer ervaring met vrije berichten in het kader van meer gebeurtenis georiënteerd werken. Gezien deze achtergrond lijkt er mij geen bezwaar te bestaan om bij de nieuwe versie van StUF ook voor de Berichtcatalogus BAG over te stappen op vrije berichten.
Momenteel worden samengestelde kennisgevingen ook gebruikt om andere afnemers dan WOZ te informeren over wijzigingen op basis van enkelvoudige kennisgevingen. Het is voor een ESB duidelijk dat een samengestelde kennisgeving (alleen) bestaat uit enkelvoudige kennisgevingen. Bij vrije berichten is dit niet vanzelfsprekend en het is dus de vraag of de ESB altijd eenduidig een soortgelijke afleiding kan blijven maken indien vrije berichten gebruikt worden.
Als de samengestelde berichten van de BAG-berichtcatalogus omgezet worden naar vrije berichten zal (hoogstwaarschijnlijk) de gebeurteniscode worden opgenomen in het stuurgegeven "stuf:functie" van het vrije bericht. Op basis van dit stuurgegeven kan de ESB afleiden dat het vrije bericht alleen uit enkelvoudige kennisgevingen bestaat. De ESB hoeft dan alleen nog de stuurgegevens van het vrije bericht te plakken aan de body van de enkelvoudige kennisgevingen.
In de overgang naar bg0320 zal de BAG-berichtcatalogus een zelfstandig koppelvlak worden met een eigen namespace. In dit geval kan de ESB zelfs al op basis van de namespace zien of een vrij bericht vertaald kan worden naar enkelvoudige kennisgevingen.
Dit lijkt mij geen goed idee om de volgende redenen:
Als we constateren dat er iets mis is met de dienstberichten, dan zou ik het probleem liever daar aanpakken in plaats van over te stappen op de meer generieke dienstberichten die bedoeld zijn om functionaliteit te realiseren die niet in de standaard berichtsoorten zijn gevat. Dit zou betekenen dat we de samengestelde kennisgevingen mogelijk moeten herzien en niet dat we ervan af zouden moeten stappen.
Als het enige voordeel is dat er wat bytes in het bericht bespaard blijven, lijkt mij dat niet opwegen tegen deze drie nadelen.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0405.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Eén van de meest gehoorde bezwaren tegen StUF is de complexiteit. Het lijkt me goed om in 0302 waar mogelijk te streven naar een groter gemak bij het gebruik van StUF. Dit doet inderdaad pijn bij partijen die hierdoor in hun programmatuur afgeschafte constructies moeten vervangen, maar die pijn moet toch een keer genomen worden.
Het afleiden van kennisgevingen uit een vrij bericht met uitsluitend update elementen is niet bar complex. De kennisgevingbody heb je al en een voorbeeld voor de stuurgegevens ook. Je moet de berichtcode, het entiteittype, het referentienummer en tijdstipBericht vullen. Het is inderdaad wel iets meer werk dan een samengestelde kennisgeving uit elkaar peuteren, maar bepaald niet schokkend.
De semantiek van het update element in een vrij bericht is net zo eenduidig beschreven als de semantiek van een enkelvoudige kennisgeving in een samengestelde kennisgeving.
Het voordeel zit hem niet in het besparen van bytes, maar in het versimpelen van StUF.
Om de vertaling van een vrij bericht met update elementen nog eenvoudiger te maken kan in de parameters voor het update element in een asynchroon vrij bericht ook het tijdstipBericht worden opgenomen, dat dan aan dezelfde spelregels moet voldoen als tijdstipBericht in de stuurgegevens van een asynchrone kennisgeving.
Tijdens de StUF Expertgroep van 21 oktober 2015 is besloten het type bericht Lk03 deprecated te maken. Voor nieuwe situaties kan dan een vrij bericht gebruikt worden. Waar het al bestaat kan het gehandhaafd blijven.
Bijgaand de uitwerking van RFC0405. Deze zal in de aankomende EG-meeting als hamerstuk behandeld worden. In geval van bezwaar, graag ruim van te voren melden via dit forum.
Bijlage
Bijgaand (zie bijlage) de Word-versie van de uitwerking van bovenstaande RFC. In Word is het voor sommigen handiger om van de ene revisie naar de andere te springen dan in PDF. Ook zijn er mogelijk nog een paar verbeteringen doorgevoerd. Dus graag deze word-versie gebruiken voor de review.
Bijlage
Het samengesteld bericht wordt nu onder andere gebruikt in de berichtencatalogus BAG. Bij de modernisering van de BAG (BAG 2.0) is nagedacht over de introductie van gebeurtenissen als concept om met de LV BAG te communiceren. Deze gebeurtenissen zouden dan de vorm van vrije berichten kunnen krijgen.
De conclusie bij BAG lijkt nu te zijn dat gebeurtenissen/vrije berichten nog een brug te ver is. Men wil nu (ook met de LV BAG) gaan werken met samengestelde berichten. Wanneer deze RFC wordt overgenomen, dan zou die weg voor de BAG niet meer openstaan. Het gebruik van samengestelde berichten als "wentraject" voor gebeurtenissen, wordt dan afgesneden. Wellicht is het toch beter om deze vorm van berichten wel mogelijk te laten, maar als best practice te definiëren dat vrije berichten de voorkeur hebben.
Tijdens de StUF Expertgroep van 16 november 2016 is besloten de uitwerking van dit RFC goed te keuren.