Het huidige verstuffingsproces verloopt in ruwweg 3 stappen:
- Informatiemodel (bijv. RSGB) wordt gedenormaliseerd (platslaan van objecttypen en relaties) ten behoeve van gegevensuitwisseling. In de huidige werkwijze wordt het platgeslagen model uitgedrukt door middel van relatiegrafieken die zijn beschreven in een zogenoemd “KeuzenVerStUFfingsdocument”.
- Het platgelagen model (relatiegrafieken) wordt omgezet naar XML Schema’s (XSD), ook wel de basisschema’s of entiteitschema’s genoemd. Deze schema’s bevinden zich in de files met extensie “_ent_basis.xsd”, bijv. “bg0310_ent_basis.xsd” voor de XSD-vertaling van de relatiegrafieken van RSGB 2.0.
- Het basisschema zoals genoemd in stap 2 (“_ent_basis.xsd”) wordt gebruikt om de generieke berichtdefinities van het sectormodel (kennisgevingen, vraag-antwoord, etc.) te genereren en voor het handmatig definiëren van vrije berichten in koppelvlakken.
Het platslaan van het informatiemodel, oftewel het opstellen van de relatiegrafieken wordt nu één keer uitgevoerd en als basis gebruikt voor alle koppelvlakken die erop gedefinieerd worden. Dit zorgt ervoor dat in alle koppelvlakken dezelfde basisstructuren worden hergebruikt voor veel voorkomende entiteiten zoals NPS, NNP en AOA (etc.). Het voordeel is dat leveranciers generieke software kunnen ontwikkelen voor het ondersteunen van meerdere StUF-koppelvlakken.
In de Haagse Pilot is men het niet eens met deze benadering. Daar vindt men dat pas op het niveau van koppelvlakken keuzes gemaakt kunnen worden voor het wel (of niet) platslaan van objecttypen en relaties. Dat houdt in dat er per koppelvlak mogelijk andere keuzes gemaakt kunnen worden. Het voordeel van deze benadering is meer vrijheid in het optimaal aansluiten bij een business behoefte (maatwerk). Nadeel is het opgeven van uniformiteit in de basisstructuren waardoor het onder andere lastiger is om generieke software te ontwikkelen.
Het gaat hier om een fundamentele keuze in het standaardisatieproces van StUF en ik ben benieuwd hoe de StUF Community en in het bijzonder de StUF Expertgroep hierover denkt.
Het hanteren van eenduidige schema's per entiteit die in het gehele (sector)model en alle koppelvlakken worden gebruikt acht ik een essentiële voorwaarde om te kunnen spreken van een StUF family. Koppelvlakken die volledig vrij en willekeurig attributen en entiteiten kunnen combineren lijken mij niet tot de family behoren.
Wat betreft de beschreven werkwijze om te komen tot de basisschema's ga ik ervan uit dat wat hier beschreven is, de werkwijze tot nu toe is. Volgens mij was het afgesproken uitgangspunt dat vanaf de versie StUF bg 03.20 deze basisschema's zo veel mogelijk/nagenoeg volledig gegenereerd zouden worden uit een UML-model (conform de werkwijze bij NEN3610). Waarbij het UML model wel een "operationele op implementatie gerichte" versie van het UML model zou zijn, als uitwerking van het zuiver semantische UML waarin RSGB 3.0 is gedefinieerd.
@Ruud: De beschreven werkwijze is inderdaad de huidige werkwijze zoals die reeds heeft geresulteerd in de sectormodellen bg0310, ztc0310 en zkn0310 en koppelvlakken zoals Zaak- en Documentservices, Prefill e-formulierenservices, etc. We zijn nu binnen KING in samenwerking met Kadaster bezig met de ontwikkeling van een nieuwe aanpak waarin we de relatiegrafieken vervangen door een formele UML representatie, het zogenaamde UGM (Uitwisselings Gegevens Model), die we op een gecontroleerde kunnen afleiden van het SIM (Semantisch Informatie Model). Vanuit het UGM kunnen we in principe direct de basisschema's genereren. Echter in de huidige pilot wordt deze mogelijkheid vooralsnog (helaas) overgeslagen. Daar worden eerst op basis van het UGM de berichtdefinities voor de eindproducten in UML worden opgesteld, dit heet het BSM (Bericht Structuur Model). Vanuit het BSM worden de koppelvlakschema's direct uit het BSM gegenereerd.
De hierboven beschreven nieuwe aanpak heeft geen invloed op de bovenstaande vraag. M.a.w. in de nieuwe aanpak zou je een vergelijkbare vraag kunnen stellen. Willen we één UGM voor alle koppelvlakken of per koppelvlak een eigen UGM? Ik denk dat jij in de nieuwe situatie ook voor de eerste optie zou kiezen (één UGM voor alle koppelvlakken)...
De StUF-standaard is ontworpen uitgaande van drie basisprincipes:
Bij de vernieuwing van de standaard zouden deze uitgangspunten gehandhaafd moeten blijven. De voordelen die deze drie uitgangspunten bieden zijn veel groter dan het nadeel dat in sommige koppelvlakken de structuur nog iets optimaler gemaakt zou knnen worden gegeven een specifieke businessbehoefte. Tegelijkertijd moet geprobeerd worden om de toetredingsdrempel te verlagen door het versimpelen van het gebruik van StUF door bijvoorbeeld simpele synchrone verzoekberichten toe te staan die eenvoudig vertaalbaar zijn naar standaard StUF-berichten. De last van de vertaling komt te liggen bij de provider van de service en de consumers kunnen werken met simpele verzoekberichten die ook naar REST vertaalbaar zijn. Deze verdeling van lasten is terecht, omdat er meer consumers dan providers zijn.
Voor Java is in de vorm van de StUFKletser een API beschikbaar voor serialisatie en deserialisatie die door minstens zes partijen wordt gebruikt. Er zijn ongetwijfeld nog meer partijen die bij de ontwikkeling van hun software gebruik maken van deze uitgangspunten van de StUF-standaard. Het loslaten van deze uitgangspunten heeft ernstige consequenties voor deze partijen.
Het bepalen van het informatiemodel per koppelvlak houdt in dat aansluitende partijen wellicht alle vormen van een bepaalde entiteit moeten gaan ondersteunen.
neem als voorbeeld een natuurlijk persoon. Deze kan als ingezetene, niet ingezetene of ander natuurlijk persoon worden gekenmerkt. Authentieke bronnen zullen echter geen onderscheid maken (bijvoorbeeld HR en GBA) tussen ingezetene en niet ingezetene en een natuurlijk persoon willen aanleveren of afnemen. Het ligt dan ook meer voor de hand om hiervoor een gemeenschappelijke entiteit te definiëren die alle types bevat. hierdoor is het voor iedereen duidelijk hoe met personen moet worden omgegaan.
Ik kan me voorstellen dat juist bij een koppelvlak als RSGB bevragingen deze gemeenschappelijke entiteit toegevoegde waarde biedt: Waarom zou een vraagsteller binnen de gemeente alleen een ingezetene zoeken? Wat als deze juist geëmigreerd is?
In RSGB 3 zijn ingezetenen en niet-ingezeten al samengevoegd. Er wordt alleen nog onderscheid gemaakt tussen Ingeschreven Natuurlijk Persoon en Ander Natuurlijk Persoon. In de Pilot RSGB Bevragingen is men het er niet mee eens dat we deze twee objecttypen hebben samengevoegd in het StUF-entiteittype Natuurlijk Persoon (NPS).
De gevolgtrekking in de alinea "Het platslaan van het informatiemodel, oftewel het opstellen van de relatiegrafieken wordt nu één keer uitgevoerd en als basis gebruikt voor alle koppelvlakken die erop gedefinieerd worden. Dit zorgt ervoor dat in alle koppelvlakken dezelfde basisstructuren worden hergebruikt voor veel voorkomende entiteiten zoals NPS, NNP en AOA (etc.). " klopt niet. Niemand bestrijdt dat de standaard eenduidig en consistent moet zijn. Dit acht Den Haag juist van het grootste belang. Om een basisstructuur voor hergebruik te realiseren is het geenszins noodzakelijk deze a-priori te definiëren voor alle relevante koppelvlakken. Wij weten nu nog niet wat wij voor deze koppelvlakken nodig zullen hebben, dit wordt bij de informatiebehoefte geïnventariseerd. Den Haag stelt voor een repository aan te leggen met alle entiteiten die zijn ontwikkeld in een bepaald koppelvlak en die men in andere koppelvlakken moet hergebruiken bij een soortgelijke behoefte. Hierbij geldt de regel: "gebruik voor hergebruik".
Cathy en André Gemeente Den Haag:
De gevolgtrekking "Dat houdt in dat er per koppelvlak mogelijk andere keuzes gemaakt kunnen worden" klopt niet. Als er geen a-priori keuzes zijn gemaakt om plat te slaan kun je ook geen keuzes maken die hiermee in strijd zijn. In ons voorstel ben je zeker niet volledig vrij in het kiezen van je koppelvlak entiteiten. Ten eerste is het informatiemodel altijd het uitgangspunt voor ieder koppelvlak. Free format is helemaal niet aan de orde. Daarnaast moet je altijd eerst de repository raadplegen of de gewenste entiteit niet al bestaat. De veronderstelling die wij vaak horen dat een standaardisatie werkgroep niet geneigd is entiteiten uit de repository te willen hergebruiken vanuit een soort van "not invented by me" emotie lijkt ons niet aannemelijk. Het eindresultaat is een repository die minder entiteiten bevat dan een a-priori gedefinieerd model omdat alleen die entiteiten worden opgenomen waaraan een echte informatiebehoefte ten grondslag ligt.
De stelling " Nadeel is het opgeven van uniformiteit in de basisstructuren waardoor het onder andere lastiger is om generieke software te ontwikkelen. "Daar vindt men dat pas op het niveau van koppelvlakken keuzes gemaakt kunnen worden voor het wel (of niet) platslaan van objecttypen en relaties"
Cathy en André Den Haag:
De zin "Vanuit het UGM kunnen we in principe direct de basisschema's genereren. Echter in de huidige pilot wordt deze mogelijkheid vooralsnog (helaas) overgeslagen" onderschrijven wij. Wij hebben aangeboden deze tool in de pilot RSGB Bevragingen te gebruiken. Echter de tool was nog niet beschikbaar. Wij hadden graag gezien wat het resultaat was van een dergelijke tool en wat de kwaliteit is van het eindresultaat zodat wij dit voorstel op zijn merites kunnen beoordelen.
Cathy & André Den Haag:
In het convenant met King over de pilot RSGB bevragingen zijn twee uitgangspunten afgesproken voor de realisatie van dit koppelvlak:
- De informatiebehoefte van gemeenten zoals gedefinieerd in de werkgroep
Het koppelvlak wordt gemaakt voor de referentiecomponent “gegevensmagazijn” in GEMMA. Deze levert geen gegevens over Ander Natuurlijk Persoon. Er is geen noodzaak om consumenten die gegevens van Ingeschreven Persoon willen afnemen op te zadelen met Ander Natuurlijk Persoon.
- RSGB v2.01
De entiteit NPS is geen onderdeel van RSGB.
Conclusie: op basis van beide uitgangspunten is er in de pilot RSGB bevragingen geen behoefte aan een gecombineerde entiteit. Voor de pilot RSGB bevragingen is NPS een kunstmatig geconstrueerde entiteit. Natuurlijk in een ander koppelvlak wel behoefte zijn aan deze entiteit. Dan zijn we prima in staat om de entiteit alsnog te creëren.
Tijdens de StUF Expertgroep van 21 december 2016 is duidelijk geworden dat de meeste EG-leden vooralsnog weinig voelen voor het voorstel. Het zou er immers toe leiden dat elk koppelvlak een andere structuur zou hanteren waardoor een generieke afhandeling van een entiteit onmogelijk wordt.
Den Haag is gevraagd haar argumenten m.b.t. dit punt aan de discussie toe te voegen (zie daarvoor de voorgaande post).
Reactie op post 7
Allereerst een vraag: Is het altijd in dezelfde volgorde staan van elementen binnen een berichtstructuur voor de gemeente Den Haag een onderdeel van het consistent en eenduidig zijn berichtstructuren of zijn berichtstructuren ook eenduidig en consistent als er verschillen in volgorde zijn?
In het eerste geval discussiëren we over de beste manier om te komen tot optimale berichtstructuren, maar zijn we het over het belangrijkste eens: een uniforme volgorde van elementen in berichtstructuren voor een entiteittype. In het tweede geval zijn we het oneens over wat consistente en eenduidige berichtstructuren zijn. In onderstaande reactie ben ik uitgegaan van het laatste.
Bij het maken van de berichtstructuren binnen StUF zijn informatiemodellen het uitgangspunt. Er wordt vanuit gegaan dat de werkgroep die een informatiemodel heeft opgesteld de informatiebehoefte van de business goed in kaart gebracht heeft. Dit uitgangspunt impliceert dat de maximale omvang gedefinieerd in het informatiemodel ook in minstens één koppelvlak nodig zal zijn.
Een voorbeeld van de koppelvlakken met de maximale omvang voor de basisgegevens zijn de koppelvlakken voor het voeden en bevragen van een gegevensmagazijn basisgegevens. Als het RSGB 3.0 de norm is voor de omvang van de Gemma referentiecomponent gegevensmagazijn basisgegevens, dan heb je voor voeden en bevragen voor elk objecttype berichtstructuren nodig die alle attributen bevatten en waarmee alle relaties kunnen worden onderhouden en bevraagd.
Per entiteit worden gegeven bovenstaand uitgangspunt op basis van de vastgestelde informatiebehoefte de maximale berichtstructuren gedefinieerd. De berichtstructuren in alle andere koppelvlakken worden van deze maximale berichtstructuur afgeleid door er elementen uit weg te laten, in technische termen door de berichtstructuur te restricten. Zo krijg je in alle koppelvlakken eenduidige en consistente berichtstructuren.
Wat ik niet goed begrijp is waarom de gemeente Den Haag bezwaren heeft tegen deze werkwijze. Waarom leidt het wijzigen van de volgorde van elementen in de berichtstructuur voor een entiteit in een specifiek koppelvlak tot significant lagere kosten bij het werken met die gewijzigde berichtstructuur in gegenereerde programmatuur? Bedenk hierbij ook dat de volgorde van de elementen in de gegenereerde API niet meer zichtbaar is. Methodes voor het vullen of uitlezen van een element kunnen per slot van rekening in willekeurige volgorde worden aangeroepen. Een gebruiker van gegenereerde code wordt dus niet geconfronteerd met de volgorde van de elementen in een bericht.
Voor partijen die geen codegeneratie gebruiken (de meeste leveranciers die op dit moment StUF intensief gebruiken in hun applicaties) leidt het gebruik van vaste berichtstructuren voor een entiteit tot zeer significante besparingen. Er hoeft per entiteit slechts één keer het vullen en uitlezen van elementen te worden gecodeerd. Dit stuk code kan vervolgens in alle koppelvlakken (huidige en toekomstige) worden ingezet.
Reactie op post 8
De status van het RSGB is hier in het geding. Voor mij is dit de door de business geformuleerde informatiebehoefte rond basisgegevens. De gemeente Den Haag lijkt het RSGB te beschouwen als een te groot informatiemodel waar objecttypen en binnen objecttypen attributen en relaties zitten waar binnen koppelvlakken geen behoefte zal blijken te zijn. Deze objecttypen en attributen en relatie zullen niet terecht komen in de door Den Haag geïntroduceerde repository, omdat er geen behoefte aan blijkt te zijn.
Reactie op post 10
Waarop baseren jullie de uitspraak dat de GEMMA referentiecomponent gegevensmagazijn basisgegevens geen Ander Natuurlijk persoon zou bevatten? Zodra je in het gegevensmagazijn ook WOZ-objecten en zakelijke rechten opneemt, zal je er Ander natuurlijke personen in moeten opnemen, omdat buitenlanders zakelijke rechten hebben en eigenaar of gebruiker van een WOZ-object kunnen zijn.
Het RSGB 2.01 kent het objecttype Natuurlijk Persoon met als subtypen Ander Natuurlijk Persoon en Ingeschreven Persoon. Ingeschreven Persoon heeft weer als subtypen Ingezetene en niet-ingezetene. De stelling dat de entiteit Natuurlijk Persoon niet voorkomt in het RSGB lijkt me derhalve niet juist.
Daarnaast lijkt het me bij het ontwerpen van herbruikbare, consistente en eenduidige berichtstructuren niet de primaire vraag of een bepaald specifiek koppelvlak het misschien graag anders zou zien. De primaire vraag is om met zo min mogelijk berichtstructuren op een redelijke (mogelijk niet optimale) wijze te voorzien is in de behoeften van alle mogelijke koppelvlakken.
In het voorbeeld van RSGB bevragingen zie ik geen grote bezwaren tegen het gebruik van de in bg0310 gedefinieerde berichtstructuur voor NPS. Ten behoeve van dit specifieke koppelvlak kan het element voor het attribuut nummer Ander Natuurlijk persoon uit de berichtstructuur verwijderd. Daarnaast kan het element typering verwijderd worden op het moment dat je in de koppelvlak specificatie specificeert dat alleen natuurlijke personen mogen worden teruggegeven die een Ingezetene c.q. een Ingeschreven Persoon zijn. In het laatste geval ga ik ervan uit dat het onderscheid tussen ingezetene en niet-ingezetene niet relevant is, want anders kan je element typering beter handhaven maar restricten tot de waarden Ingezetene en Niet-ingezetene.
Realiseer je wel dat je bij een dergelijke definitie in de problemen kunt komen bij het toepassen ervan op een gegevensmagazijn met zakelijk gerechtigden of eigenaren/gebruikers van WOZ-objecten erin, want hoe ga je er voor zorgen dat deze personen niet ook worden teruggegeven.
Voor de bestaande leveranciers van gegevensmagazijnen is het waarschijnlijk het goedkoopste om de bestaande functionaliteit voor vraag/antwoord te hergebruiken bij de implementatie van het RSGB-bevragingen koppelvlak. De introductie van nieuwe berichtstructuren maakt dit zonder enige twijfel duurder voor hen. Waarom is het voor de gemeente Den Haag zo belangrijk om in plaats van een teruggesnoeide berichtstructuur gebaseerd op de NPS-entiteit uit bg0310 een eigen nieuw gedefinieerde berichtstructuur te gebruiken die op dit moment door geen enkele leverancier van een gegevensmagazijn wordt ondersteund. Waarom wordt de implementatie van het koppelvlak hierdoor significant goedkoper voor de gemeente Den Haag?
Correctie van laatste alinea van 8
De stelling dat uniformiteit in de basisstructuren wordt opgegeven is onjuist. Iedere onderbouwing van deze stelling ontbreekt. Ook zou ik het op prijs stellen om zaken die de werkgroep RSGB bevragingen "zou vinden" zelf te formuleren, in plaats van dat ons allerlei meningen in de mond worden gelegd.
De referentiecomponent “gegevensmagazijn” in GEMMA levert geen gegevens over Ander Natuurlijk Persoon. Daarmee wordt bedoeld dat in dit koppelvlak geen methoden zijn gedefinieerd om Ander Natuurlijk Persoon op te zoeken en te raadplegen. Dat is ook logisch, want er is geen bronhouder gedefinieerd die bij wet verantwoordelijk wordt gehouden voor het bijhouden van Niet Ingeschreven Personen :-). In ons koppelvlak is de WOZ buiten beschouwing gelaten omdat in de werkgroep is vastgesteld dat daar vooralsnog geen binnengemeentelijke afnemers voor zijn.
Inmiddels hebben wij ook de BRK geïmplementeerd en komt Ander Natuurlijk Persoon voor als relatie van Kadastrale Onroerende Zaak. In het koppelvlak RSGB bevragingen is een methode opgenomen om een Kadastrale Onroerende Zaak te zoeken op het zakelijk recht van een Ander Natuurlijk Persoon (ook van een Ander Niet Natuurlijke Persoon overigens).
Het Zoeken van kadastraal Onroerende Zaak op het zakelijk recht van een Ingeschreven Persoon kan op basis van een BSN, en het zoeken van een Ingeschreven Natuurlijke Persoon kan op heel veel verschillende manieren zodat die BSN altijd wel gevonden wordt. Het zoeken van een kadastraal onroerende zaak op het zakelijk recht van een Ander Natuurlijk persoon kan maar op een beperkt aantal manieren (op geslachtsnaam, geboortedatum). Die zoekmogelijkheden verschillen enorm van elkaar. Daarom is besloten om twee verschillende operaties definiëren, zodat een consument direct snapt welke zoekargumenten hij moet meegeven als hij op een buitenlandse eigenaar zoeken. Het zoekpad wordt per entiteit expliciet gemaakt, de consument krijgt per entiteit een andere instructie.
Nog steeds geldt: in dit koppelvlak is geen behoefte aan een gecombineerde entiteit NPS. Voor de pilot RSGB bevragingen zou het verplicht gebruik van deze kunstmatig geconstrueerde entiteit zelfs afbreuk doen aan de te bieden functionaliteit. Als we gedwongen worden deze UGM entiteit NPS te gebruiken en de bijbehorende zoekpaden op 1 hoop moeten gooien, is de kans groot dat een consument zoekargumenten meegeeft voor de verkeerde entiteit, en niet vindt wat hij zoekt. Dat is zo ongeveer het ergste wat er is, zeker als hij het wel had kunnen vinden met de juiste instructie.
Waarmee ik zeker niet wil zeggen dat niemand ooit gebruik moet maken van gecombineerde entiteit NPS. In DIT KOPPELVLAK van RSGB bevragingen is geen behoefte aan deze entiteit, IN EEN ANDER KOPPELVLAK mogelijk wel.
Ons punt is: maak ze alleen als er behoefte aan is. Plaats ze in een repository, en hergebruik ze in andere koppelvlakken zodat de consistentie over de koppelvlakken heen kan worden bewaakt. Maar alleen als daar functionele noodzaak voor is.
Gebruik voor hergebruik dus.
Het RSGB 3.0 heeft Ander Natuurlijk Persoon gedefinieerd, ook al is er geen bronhouder voor. Een discussie over het al dan niet onlogisch zijn van deze keuze moet niet hier gevoerd worden, maar met de opstellers van het RSGB.
Ik ben niet tegen het definiëren van meerdere operaties en ik snap niet wat de relevantie van de opmerking over het opnemen van een aparte operatie voor het zoeken op Ander Natuurlijk Persoon is voor de discussie over uniforme basisstructuren.
Wat in elk geval geldt is dat er in dit koppelvlak behoefte is aan de subtypen Ander Natuurlijk Persoon en Ingeschreven Persoon van Natuurlijk Persoon. De vraag waar de discussie om draait is of dit op het niveau van de berichtstructuren moet leiden tot twee verschillende berichtstructuren. Ik zou graag zien dat Den Haag dit beargumenteert door middel van antwoorden op de vragen die ik heb gesteld in post 12. Ik blijf van mening dat de functionaliteit prima gedefinieerd kan worden met behulp van één berichtstructuur voor NPS, maar ja dit is een herhaling van zetten.
Geen gebruik voor hergebruik dus, maar uniforme berichtstructuren, waar de berichtstructuren in een koppelvlak via restriction van worden afgeleid, zie ook mijn posts 4 en 14.
Reactie op post 18
MaartenvdB: Allereerst een vraag: Is het altijd in dezelfde volgorde staan van elementen binnen een berichtstructuur voor de gemeente Den Haag een onderdeel van het consistent en eenduidig zijn berichtstructuren of zijn berichtstructuren ook eenduidig en consistent als er verschillen in volgorde zijn? In het eerste geval discussiëren we over de beste manier om te komen tot optimale berichtstructuren, maar zijn we het over het belangrijkste eens: een uniforme volgorde van elementen in berichtstructuren voor een entiteittype. In het tweede geval zijn we het oneens over wat consistente en eenduidige berichtstructuren zijn. In onderstaande reactie ben ik uitgegaan van het laatste. Bij het maken van de berichtstructuren binnen StUF zijn informatiemodellen het uitgangspunt. Er wordt vanuit gegaan dat de werkgroep die een informatiemodel heeft opgesteld de informatiebehoefte van de business goed in kaart gebracht heeft. Dit uitgangspunt impliceert dat de maximale omvang gedefinieerd in het informatiemodel ook in minstens één koppelvlak nodig zal zijn.
Reactie Cathy: Uitgangspunt is onjuist, dit uitgangspunt impliceert dat alle koppelvlakken samen de maximale omvang van het informatiemodel bevatten.
Voorts is de vraag: Wat is uniform? Pilot uitgangspunt: altijd op basis van een RSGB entiteit, tenzij RSGB niet voorziet in de behoefte. In de pilot wordt niet gestreefd naar uniformiteit zoals in StUFbg als doel op zich, omdat dit geen bijdrage levert aan de doelstellingen die we met standaardisatie willen bereiken. Een sprekend voorbeeld is het gebruik van een zoekfilter t.o.v. van het antwoord dat je terugkrijgt. In StUFbg zijn beiden gelijk. In de pilot is het antwoordbericht gelijk aan RSBG, het zoekfilter daarentegen niet, want het dient een ander doel. In het antwoordbericht heeft een geslachtsnaam bijvoorbeeld maximaal 200 karakters. Een zoekfilter met dergelijke kenmerken is zinloos, ik heb nog nooit iemand in een zoekvraag 200 karakters zien intypen. De zoekvraag kan wildcards bevatten, het antwoord niet. Hier rucksichtslos RSGB toepassen of uitgaan van een maximaal vraagbericht met dezelfde definities van elementen is niet zinvol.
Maarten:
Een voorbeeld van de koppelvlakken met de maximale omvang voor de basisgegevens zijn de koppelvlakken voor het voeden en bevragen van een gegevensmagazijn basisgegevens. Als het RSGB 3.0 de norm is voor de omvang van de Gemma referentiecomponent gegevensmagazijn basisgegevens, dan heb je voor voeden en bevragen voor elk objecttype berichtstructuren nodig die alle attributen bevatten en waarmee alle relaties kunnen worden onderhouden en bevraagd.
Reactie Cathy:
Interessante observatie, echter voeden en bevragen zijn twee totaal verschillende gebruiksscenario's, waarvoor mogelijk een andere berichtstructuur nodig is. Over het voeden kan ik op dit moment niks zeggen. Dit lijkt me handig om te onderzoeken in de context van een vernieuwde koppelvlakstandaard voor synchronisatie.
Maarten:
Per entiteit worden gegeven bovenstaand uitgangspunt op basis van de vastgestelde informatiebehoefte de maximale berichtstructuren gedefinieerd. De berichtstructuren in alle andere koppelvlakken worden van deze maximale berichtstructuur afgeleid door er elementen uit weg te laten, in technische termen door de berichtstructuur te restricten. Zo krijg je in alle koppelvlakken eenduidige en consistente berichtstructuren.
Reactie Cathy:
Er zijn andere manieren om dit te bewerkstelligen, de pilotgroep is het eens met het uitgangspunt van eenduidigheid en consistentie. Restricten heeft aangetoond op gespannen voet te staan met een object georiënteerde implementatie (zie SIG rapport).
Maarten:
Wat ik niet goed begrijp is waarom de gemeente Den Haag bezwaren heeft tegen deze werkwijze. Waarom leidt het wijzigen van de volgorde van elementen in de berichtstructuur voor een entiteit in een specifiek koppelvlak tot significant lagere kosten bij het werken met die gewijzigde berichtstructuur in gegenereerde programmatuur?
Reactie Cathy
Heeft iemand uit de werkgroep dit gezegd? Dit is geen standpunt van de pilotgroep.
Maarten: Bedenk hierbij ook dat de volgorde van de elementen in de gegenereerde API niet meer zichtbaar is. Methodes voor het vullen of uitlezen van een element kunnen per slot van rekening in willekeurige volgorde worden aangeroepen. Een gebruiker van gegenereerde code wordt dus niet geconfronteerd met de volgorde van de elementen in een bericht.
Reactie Cathy
Helemaal mee eens, dit onderbouwt het argument dat volgorde in berichten niet relevant is, want de ontwikkelaar wordt na code generatie niet geconfronteerd met deze volgorde.
Maarten:
Voor partijen die geen codegeneratie gebruiken (de meeste leveranciers die op dit moment StUF intensief gebruiken in hun applicaties) leidt het gebruik van vaste berichtstructuren voor een entiteit tot zeer significante besparingen. Er hoeft per entiteit slechts één keer het vullen en uitlezen van elementen te worden gecodeerd. Dit stuk code kan vervolgens in alle koppelvlakken (huidige en toekomstige) worden ingezet.
Reactie Cathy:
De leveranciers hebben in StUFbg geen keuze om te genereren, het kan simpelweg niet. Hebben zij die keuze wel, zoals in RSGB bevragingen, dan kan men per koppelvlak bij het bouwen van de applicatie opnieuw genereren. Daarnaast is in het algemeen hergebruik van code niet afhankelijk van een vaste berichtenstructuur, maar van de manier waarop deze code wordt gebruikt (d.m.v. een library waar slechts op 1 plaats onderhoud hoeft te worden uitgevoerd). In het geval van codegenerator kan ook met deze library rekening worden gehouden.
Maarten:
Het RSGB 3.0 heeft Ander Natuurlijk Persoon gedefinieerd, ook al is er geen bronhouder voor. Een discussie over het al dan niet onlogisch zijn van deze keuze moet niet hier gevoerd worden, maar met de opstellers van het RSGB.
Reactie Cathy:
Het punt is dat het zoeken en raadplegen van een Ander Natuurlijk Persoon geen requirement is in het koppelvlak RSGB bevragingen. Het enige waarvoor we Ander Natuurlijk Persoon nodig hebben is voor het zoeken van een Kadastrale Onroerende Zaak. M.a.w Ander Natuurlijk persoon is geen te bevragen entiteit, maar een entiteit als zoekargument voor het zoeken van de entiteit Kadastraal Onroerende Zaak.
Maarten:
Ik ben niet tegen het definiëren van meerdere operaties...
Reactie Cathy: mooi, we zijn het eens.
Maarten: ...en ik snap niet wat de relevantie van de opmerking over het opnemen van een aparte operatie voor het zoeken op Ander Natuurlijk Persoon is voor de discussie over uniforme basisstructuren.
Reactie Cathy: Henri agendeert hier het verplicht gebruik van een gecombineerde StUF entiteit NPS als uniforme basisstructuur uit het zogenaamde Universeel Gegevens Model UGM, waarin apriori "verstuffing" plaatsvindt van het RSGB. Ik stel vast dat er in dit koppelvlak geen functionele noodzaak/behoefte is om deze gecombineerde entiteit te gebruiken. Verplicht gebruik is schadelijk, zoals in post 17 beargumenteerd. Gebruik van 2 RSGB entiteiten ipv 1 StUF NPS entiteit is explicieter, waarmee de bruikbaarheid wordt verbeterd.
Maarten: wat in elk geval geldt is dat er in dit koppelvlak behoefte is aan de subtypen Ander Natuurlijk Persoon en Ingeschreven Persoon van Natuurlijk Persoon.
Reactie Cathy: mee eens, er is behoefte aan beide typen als separate entiteit.
Maarten:
De vraag waar de discussie om draait is of dit op het niveau van de berichtstructuren moet leiden tot twee verschillende berichtstructuren.
Reactie Cathy:
Onjuiste vraagstelling, het leidt tot 2 berichten in 1 berichtenstructuur (namelijk RGSB-bevragingen) en per bericht een andere entiteit als basis voor de filter.
Maarten:
Geen gebruik voor hergebruik dus, maar uniforme berichtstructuren, waar de berichtstructuren in een koppelvlak via restriction van worden afgeleid, zie ook mijn posts 4 en 14.
Reactie Cathy:
Ik lees hier: conceptuele elegantie voor bruikbaarheid en ondubbelzinnigheid. Daarover verschillen wij van mening.
@Cathy,
Allereerst hartelijk dank voor je uitgebreide inhoudelijke reactie. De verschillen in visie worden zo helderder.
Naar aanleiding van je eerste reactie hierboven vraag ik me af of de verschillen wel zo groot zijn. Ik ben het namelijk volledig eens met het in koppelvlakken definiëren van berichtstructuren voor zoekfilters conform de eisen die je stelt. Ik stel slechts één extra eis: de elementen moeten een deelverzameling zijn van de elementen in de maximale structuur en ze moeten in die deelverzameling in dezelfde volgorde staan als in de maximale structuur. Waarachtig geen zware of enorm beperkende eis. Het terugbrengen van de lengte van bijv. de geslachtsnaam of het definiëren van een minimale lengte voor de geslachtsnaam in de structuur voor een zoekfilter. Technisch geformuleerd is de eis dat de berichtstructuur in het zoekfilter logisch gesproken een restriction moet zijn van de maximale berichtstructuur. In een koppelvlak schema hoef je deze berichtstructuur niet als restriction te definiëren, mits het feitelijk wel een restriction is. De software voor het genereren van koppelvlakken die King op dit moment ontwikkelt, zal dit faciliteren.
Als er extra parameters nodig zijn bij het zoeken (bijv. geen overledenen), dan zullen deze een plaats moeten krijgen in het parameters-element van een vrij bericht. Je kunt die conform StUF niet op een andere manier kwijt in het bericht. Standaardisatie doet soms een beetje pijn.
Om te voorkomen dat de discussie al te theoretisch en principieel wordt, lijkt het me zinvol om de schema's van het koppelvlak van de pilotgroep ook eens te ontwerpen conform de nieuwe inzichten rond StUF. De Expertgroep heeft in de vergadering van januari een nieuwe werkwijze rond het gebruik van xsi:nil="true" en StUF:noValue vastgesteld. We hebben daarbij gebruik gemaakt van inzichten uit de schema's van de pilotgroep. We kunnen dan op basis van de verschillen tussen beide schema's de discussie verder voeren.
Tijdens de StUF Expertgroep van 15 maart 2017 is besloten om op basis van deze discussie geen RFC voor het 'ontwikkel' spoor aan te maken. In het kader van dat spoor kiest de StUF Expertgroep voor uniforme basisstructuren.
De StUF Expertgroep ziet dit wel als een geschikt onderwerp voor het 'ontdekken' spoor.