De XSD van de BAG berichtencatalogus dwingt voor een braWGW kennisgeving de volgende volgorde van de Lk01 berichten af: wplLk01-inmetenGrens, vervolgens aoa, opr, aoa, ligsta, ogo, otr, vbo, wplLk01-intrekken, wplLk01-opvoeren.
Volgens het BAG processenhandboek moeten eerst de nieuwe woonplaatsen worden opgevoerd, daarna de opr en aoa worden omgehangen en tenslotte de oude woonplaatsen worden opgehangen. Zie pagina 109 voor hun argumentering
Wij stellen voor de volgorde in de BAG berichtencatalogus af te stemmen op de volgorde in het BAG processenhandboek.
Tevens stellen wij voor de huidige complexe nesting van sequence /choice / choice / sequence te vereenvoudigen tot sequence / choice.
di, 30-10-2012 - 15.52u
#1
BAG berichtencatalogus en Wijzigen grens woonplaats.
Ik ben het met je eens dat de huidige structuur van braWGW_Lk03 nodeloos complex is. Als je de beide choices na de meeervoudig toegestane choice verwijderd dan kan je nog steeds dezelfde structuur realiseren.
De XSD dwingt voor braWGW echter niet de door jou geschetste volgorde af.
Daar zorgt immers de eerste choice wel voor.
Waar je wel weer gelijk in hebt is dat de sequence van 'BG:wplLk01-intrekken' gevolgd door 'BG:wplLk01-opvoeren' in de verkeerde volgorde staat.
Mensen, denk toch is een keer na.
Wat is het nut van een choice in een choice?
Wat is het nut van een sequence in een choice?
Wat is het gevolg van een sequence in een choice?
Wat is het gevolg als een sequence intrekken-opvoeren WPL staat binnen een choice waarin een opr omgehangen wordt van de oude naar de nieuwe woonplaats?
Kortom:
- die sequence moet eruit, anders kun je een straat niet omhangen
- de structuur is onnodig ingewikkeld
Nadere bestudering van het processenhandboek leert me dat de laatste sequence er inderdaad uit moet.
Zelfs correctie van de volgorde geeft niet de mogelijkheid om de in het processenhandboek beschreven volgorde te realiseren.
Daar heb ik inderdaad even overheen gekeken.
Ik neem overigens aan dat je niet het nut van een choice in een choice of een sequence in een choice ter discussie stelt maar
dat je het nut daarvan in DEZE situatie ter discussie stelt.
Voor het gemak heb ik het gewenste content model even in illustratie 1 van de bijlage geplaatst.
In illustratie 2 heb ik nog een andere optie uitgewerkt waarmee je de gewenste structuur mogelijk nog strakker modelleert,
kijk er maar eens naar. wplLk01-inmetenGrens heb ik daarin overigens maar even optioneel gemaakt omdat uit het processenhandboek
niet duidelijk werd wat daar de functie van is en waar dit in het proces moet worden uitgevoerd.
Misschien heb jij nog ideeen hoe dat het beste te plaatsen.
Bijlage
wplLk01-inmetenGrens wordt gebruikt als de grens van een woonplaats wordt gewijzigd, waarbij in het gewijzigde grondgebied dat is toegevoegd aand de woonplaats en/of daarvan is afgesplitst zich geen BAG objecten bevinden. In dat geval volstaat mbt deze woonplaats dit bericht.
Als zich in het grondgebied wel BAG objecten bevinden dan moet de nieuwe woonplaats (nieuwe code, zelfde naam, nieuwe geometrie) worden opgevoerd, de BAG objecten worden omgehangen van de oude woonplaats naar de nieuwe woonplaats en daarna de oude woonplaats worden ingetrokken.
Let wel dat bij 1 woonplaatsgrenswijziging meerdere woonplaatsen zijn betrokken. Zodat bovenstaande geldt voor alle woonplaatsen betrokken in een woonplaatsgrenswijziging, welke mutaties in 1 samengestelde kennisgeving bekend worden gemaakt.
Omdat OPR/AOA/PND/TGO objecten moeten worden omgehangen van oude woonplaats naar nieuwe woonplaats is het dus noodzakelijk dat eerst alle nieuwe woonplaatsen worden opgevoerd, daarna de overige objecten worden omgehangen en daarna de oude woonplaatsen worden afgevoerd.
Op welke plek in dit rijtje de eenvoudige woonplaatsgrenswijziging met een wplLk01-inmetenGrensbericht wordt opgenomen kan mij persoonlijk niet zoveel schelen, als het maar opgenomen kan worden in de samengestelde kennisgeving. Wel heb ik een lichte voorkeur dat de plek willekeurig is.
Wat de voorstellen betreft gaat mijn voorkeur uit naar illustratie 1. De totale gebeurtenis is al ingewikkeld genoeg. Keep it simple.
In illustratie 2 zitten een paar fouten. 1..00 bij wpl-opvoeren, opr en wpl_intrekken moeten zijn 0..00. Zie bovenstaande betoog en het BAG processenhandboek.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0130.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten