Marteyn Heijlaerts van Gouw IT meldt een probleem bij een braGHO_Lk03 bericht (BAG-WOZ) in de volgende situatie:
Wij gaan een openbare ruimte (OPR) gedeeltelijk hernoemen, daarom trekken wij het huidige voorkomen in en leveren we conform het XSD minimaal twee nieuwe voorkomens aan. Daarnaast leveren we de betrokken AOA objecten mee, die gewijzigd worden n.a.v. deze gebeurtenis.
In deze situatie geeft in het StUF Testplatform regel BGWZ000004 een fout terug. Regel BGWZ000004 stelt (op basis van Berichtcatalogus bg0310-BAG) dat de Lk01 berichten moeten worden gesorteerd op volgorde tijdstipRegistratie, tijdvakGeldigheid, berichtsoort en verwerkingssoort.
Wanneer in een bericht oprLk01-intrekken en oprLk01-opvoeren gelijke tijdstipRegistratie en tijdvakGeldigheid (en uiteraard gelijke berichtsoort oprLk01) hebben, moet dus gesorteerd worden op verwerkingssoort.
Deze leverancier vult bij de oprLk01-intrekken verwerkingssoort="W" en bij oprLk01-opvoeren verwerkingssoort="T". Volgens de regel moet in het bericht dan T (toevoegen) staan en daarna W (beëindiging).
Maar dat mag niet, want er komt een schemavalidatiefout wanneer oprLk01-opvoeren vóór oprLk01-intrekken wordt geplaatst.
Eerste reactie van Robert Melskens:
Ik vermoed dat hier het schema in tegenspraak is met de documentatie behorende bij de Berichtencatalogus BAG.
En dan heb ik het over de elementen oprLk01-intrekken en oprLk01-opvoeren. De waarde van het ‘mutatieSoort’ attribute bij ‘oprLk01-intrekken’ en ‘oprLk01-opvoeren’ is overigens beperkt tot ‘W’ resp.‘T’.
De regels over de sortering in de documentatie behorende bij de BAG berichtencatalogus zeggen echter dat bij een gelijk ‘tijdstipRegistratie’, gelijk ‘tijdvakGeldigheid/beginGeldigheid’ en gelijk ‘berichtsoort’ de berichten in de volgorde F (correcties), T (toevoeging), W (beëindiging) en W (overige wijzigingen) moeten staan. Ik neem overigens aan dat men hierbij doelt op de waarde van het ‘mutatieSoort’ attribute.
‘T’ en ‘W’ in het schema staan daar dus in een geheel andere volgorde dan de documentatie aangeeft.
Logisch dat het dan niet lukt om het bericht te valideren.
Conclusie
Hier is duidelijk sprake van een erratum.
Een erratum dat in principe niet backwards compatible is. Dat lijkt me echter geen probleem aangezien we n.m.m. veilig kunnen aannemen dat nog geen enkele leverancier dit deel van het braGHO_Lk03 bericht heeft geïmplementeerd. Anders was dit probleem allang veel eerder gemeld.
Wellicht komen gelijksoortige fouten op meer plaatsen in de bAG berichtencatalogus voor.
Dit wijzigingsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0388.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
In de bijgaande zip file vindt je een voorstel voor het oplossen van het hierboven geschetste probleem. De beschrijving van de oplossing staat in het pdf bestand 'verantwoording ONV0388.pdf' (eveneens te vinden in de zip file).
Bijlage
In de voorggestelde oplossing heb je nog minder 'controle'. Je zou in deze oplossing ook twee intrekkingen en één opvoer kunnen sturen. Dit zou niet mogen (en kan ook niet volgens de oude structuur).
Liever: structuur onveranderd laten en (beter) beschrijven hoe het zich verhoudt tot de sorteringsregels.
In een nieuwe versie van het koppelvlak zouden we kunnen kijken naar de (on-)mogelijkheid van een structuur die de volgorde beter vastlegt in het schema zelf.
Tijdens de StUF Expertgroep van 17 februari 2016 is het voorstel afgekeurd. Het bericht is nu immers al bij diverse leveranciers als zodanig geïmplementeerd daarom is besloten het bericht te houden zoals het is en de STP zo aanpassen dat dit bericht wel wordt goedgekeurd. In een volgende versie van het koppelvlak moet het wel gecorrigeerd worden. In een volgende versie moet zelfs de sorteerlogica helemaal tegen het licht aangehouden worden.
Het onderhoudsverzoek is omgezet naar een RFC (RFC0388).