Het is momenteel een best practice om de toplevel-elementen van berichten te definiëren in de eigen namespace van het koppelvlak (dus niet meer in de namespace van het sectormodel waarop het gebaseerd is). Als je het echt netjes wilt doen moeten ook alle andere elementen (en attributen) die tot het koppelvlak behoren in de eigen namespaces worden opgenomen. Dit leidt tot een technisch probleempje in StUF 3.01 omdat je dan niet meer in alle gevallen kunt zien tot welke namespace een entiteittype behoort. In de bijlage van deze post is een RFC geformuleerd hoe dit probleem opgelost kan worden. Mijn voorstel is om deze RFC mee te nemen in StUF 3.02.
vr, 22-05-2015 - 14.42u
#1
RFC voor StUF 3.01: Waardenbereik XML-attribuut “entiteittype” uitbreiden met namespace qualifier.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0391.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 16-9-2015 is besloten dit RFC toe te voegen aan de lijst met in StUF 3.02 op te lossen RFC's.
Tijdens de StUF Expertgroep van 21-10-2015 waren de meningen verdeeld of de voorgestelde oplossing StUF eenvoudiger maakt of juist complexer. Uiteindelijk is besloten dat Henri de RFC herformuleert.
In een notendop ziet het hierboven beschreven voorstel er zo uit:
<geoBAG:ligLk01 xmlns:StUF="http://www.egem.nl/StUF/StUF0301" xmlns:BG="http://www.egem.nl/StUF/sector/bg/0310"
xmlns:geoBAG="http://register.geostandaarden.nl/xmlschema/geobag/1.0"...>
<geoBAG:stuurgegevens>
<StUF:berichtcode>Lk01</StUF:berichtcode>
...
<StUF:entiteittype>BG:LIG</StUF:entiteittype>
</geoBAG:stuurgegevens>
<geoBAG:parameters>
<StUF:mutatiesoort>T</StUF:mutatiesoort>
<StUF:indicatorOvername>V</StUF:indcatorOvername>
</geoBAG:parameters>
<geoBAG:ligplaats StUF:entiteittype="BG:LIG" StUF:verwerkingsoort="T" >
<BG:identificatie>123456789</BG:identificatie>
…
<BG:aot.status>Verblijfsobject buiten gebruik</BG:aot.status>
<BG:aot.geconstateerd>J</BG:aot.geconstateerd>
…
</geoBAG:ligplaats>
</geoBAG:gmvDi01>
Om aan te geven bij welke namespace een entiteittype hoort wordt de namespace qualifier gebruikt in de waarde van het entiteittype. Een aantal leden van de expertgroep gaven aan dat deze nieuwe syntax lastig is voor parsers. Dit probleem kan opgelost worden door het attribute "StUF:ne" (namespace entiteittype) te introduceren waarin de volledige namespace uri dat bij het entiteittype hoort kan worden opgenomen. Hieronder een voorbeeld:
<geoBAG:ligLk01 xmlns:StUF="http://www.egem.nl/StUF/StUF0301" xmlns:BG="http://www.egem.nl/StUF/sector/bg/0310"
xmlns:geoBAG="http://register.geostandaarden.nl/xmlschema/geobag/1.0"...>
<geoBAG:stuurgegevens>
<StUF:berichtcode>Lk01</StUF:berichtcode>
...
<StUF:entiteittype StUF:ne="http://www.egem.nl/StUF/sector/bg/0310"> LIG</StUF:entiteittype>
</geoBAG:stuurgegevens>
<geoBAG:parameters>
<StUF:mutatiesoort>T</StUF:mutatiesoort>
<StUF:indicatorOvername>V</StUF:indcatorOvername>
</geoBAG:parameters>
<geoBAG:ligplaats StUF:ne="http://www.egem.nl/StUF/sector/bg/0310" StUF:entiteittype="LIG" StUF:verwerkingsoort="T" >
<BG:identificatie>123456789</BG:identificatie>
…
<BG:aot.status>Verblijfsobject buiten gebruik</BG:aot.status>
<BG:aot.geconstateerd>J</BG:aot.geconstateerd>
…
</geoBAG:ligplaats>
</geoBAG:gmvDi01>
Het nadeel van deze benadering is wel dat de berichten een stuk groter en minder leesbaar worden. Ben benieuwd of iemand een betere oplossing weet...
Naast de nadelen die Henri zelf al noemt is een ander nadeel van het laatste voorstel van hem dat er weer een extra attribuut wordt toegevoegd.
Ik heb daarom een ander voorstel uitgewerkt waarbij het aantal attributen gelijk blijft aan het huidige aantal en waarin we in de waarde van het attribuut geen namespaceprefix hoeven op te nemen.
Het voorstel komt er op neer dat we het attribute 'entiteitType' niet meer definieren in de StUF onderlaag maar in de namespace van het sectormodel of koppelvlak waarin entiteiten worden gedefinieerd. De entiteiten in die namespace gebruiken dan ook dat attribute waardoor aan de namespace waarin dat attribuut is gedefinieerd kan worden afgelezen in welke namespace de entiteit is gedefinieerd. Zie hieronder een fragment:
...
<ZKN:heeftBetrekkingOp ZKN:entiteittype="ZAKOBJ" StUF:verwerkingssoort="S">
<ZKN:gerelateerde>
<ZKN:adres BG:entiteittype="AOA" StUF:verwerkingssoort="V">
....
</ZKN:heeftBetrekkingOp>
...
Ik heb bijgaande een volledig voorbeeld gevoegd met daarbij ook de aangepaste schema's.
Bijlage
Hoi Robert, goede brainwave! Jouw voorstel is een absolute verbetering, een soort ei van Columbus. Volgens mij kunnen we dit voorstel a.s. woensdag zelfs al als een hamerstuk behandelen. Dank voor je snelle reactie!
Technisch een charmante oplossing. Vanuit het oogpunt van standaardisatie ben ik minder enthousiast, omdat je nu in allerlei namespaces een attribute introduceert dat in wezen overal dezelfde betekenis en dat om extra semantiek aan te duiden in een andere namespace zit.
Mijn voorkeur gaat toch uit naar een extra attribute in de StUF-namespace dat alleen gebruikt hoeft te worden als de namespace van het element afwijkt van de namespace van het aangeduide entiteittype, omdat die oplossing intuïtiever en simpeler is in het gebruik. Op het hoogste niveau in koppelvlakken zal het extra attribute gebruikt moeten, omdat het element dan in de namespace van het koppelvlak zit en de StUF-entiteit in de namespace van het sectormodel. Het komt dus wel vaker voor dan nu het geval is.
Ik heb overigens geen zwaarwegende bezwaren als anderen liever voor de oplossing van Robert kiezen.
Tijdens de StUF Expertgroep van 18 mei 2016 is er flink gediscusieerd over het nut van dit voorstel wat de complexiteit van StUF verhoogd. Maarten en Mark hebben vervolgens uitgelegd waarom deze constructie gewenst is. Het komt er op neer dat een bericht beter te interpreteren is zonder dat kennis van het schema nodig is, een bericht wordt zelfbeschrijvend. Daarop werd aangegeven dat we eerst maar eens moesten discusieren over de vraag of een bericht zelfbeschrijvend moet zijn. Zelfs de noodzaak van het attribute entiteitType werd ter discussie gesteld.
Uiteindelijk is Henri gevraagd het voorstel alvast zo aan te passen dat in de waarde van het attribute entiteitType een prefix wordt toegevoegd gevolgd door een ':'. De prefix hoeft niet gelijk te zijn aan de namespaceprefix maar bevat de code van het sectormodel (niet 'bg0310' maar 'bg').
In het kader van het project waarbij KING haar processen voor het beheer- van de standaarden en de tooling die gebruikt wordt onder de loep neemt heb ik geprobeerd om het met onderhoudsverzoek ONV0401 te verwerken. Daarbij liep ik er tegenaan dat het onmogelijk is om het attribute ‘StUF:entiteittype’ als attribute in de StUF namespace te definieren EN voor elke specifieke situatie waarin dat attribute moet worden gebruikt een eigen enumeratielijst te definiëren.
Op dit moment wordt het attribute als globaal attribute gedefinieerd in de StUF namespace waardoor er aan gerefereerd kan worden in andere namespaces. Het datatype van dit attribute is echter daardoor voor elke situatie wel gelijk. Het is nl. onmogelijk om dit attribute in de StUF namespace meerdere keren onder dezelfde naam globaal te definiëren met steeds een andere enumeratielijst.
De enige mogelijkheid waarbij we toch steeds gebruik kunnen maken van dezelfde attributenaam met voor elke specifieke situatie een eigen enumeratielijst is als we het attribuut lokaal gaan definiëren. Dat betekent echter dat dit attribuut in de namespace van de koppelvlakken komt te staan waardoor er een situatie ontstaat die ik in reactie #5 beschrijf.
Indien de StUF Expertgroep van mening blijft dat het zelfbeschrijvend zijn van de berichten een essentieel onderdeel van StUF is en we het attribute ‘entiteittype’ willen behouden zie ik op dit moment slechts de volgende opties:
Ik ben benieuwd of andere leden van deze community nog andere mogelijkheden zien.
Ik opteer dan voor de optie in #5. Twee vliegen in één klap: De in de expertgroep voorgestelde oplossing om wel de code maar niet de versie van een sectormodel op te nemen als prefix maakt de berichten bij nadere beschouwing niet echt zelf beschrijvend. Je kunt toch het gebruik van fixed waarden vermijden.
Ik opteer ook voor de oplossing zoals voorgesteld door Robert in post #5. In de aankomende bijeenkomst van de StUF Expertgroep zal dit RFC worden behandeld als hamerstuk.
Tijdens de StUF Expertgroep van 15 juni 2016 is het voorstel van Robert (reactie #5), dat tijdens de vorige vergadering nog is afgewezen, alsnog goedgekeurd.
In de uitwerking van dit voorstel is het onduidelijk hoe we met het stuurgegeven
<StUF:entiteittype>LIG</StUF:entiteittype>
om moeten gaan. We kunnen hier namelijk niet de namespace-prefix StUF vervangen door BG. We kunnen dit probleem oplossen door entiteittype te splitsen in twee elementen (een namespace- en een naamdeel):
<geoBAG:stuurgegevens>
<StUF:berichtcode>Lk01</StUF:berichtcode>
...
<StUF:entiteittype>
<StUF:namespace>BG</StUF:namespace>
<StUF:naam>LIG</StUF:naam>
</StUF:entiteittype>
</geoBAG:stuurgegevens>.
De waarde BG in het namespace-element verwijst naar dezelfde namespace (bijvoorbeeld "http://www.stufstandaarden.nl/basisschema/bg0320") als de namespace prefix BG in het onderstaande XML-fragment:
<geoBAG:ligplaats BG:entiteittype="LIG" StUF:verwerkingsoort="T">
…
</geoBAG:ligplaats>.
Ik vraag me af of dit voorstel handig is, want je moet hiervoor de namespace-prefix van het sectormodel definiëren op het berichtelement of op het stuurgegevens element. Het lijkt mij handiger om hetzij het element namespace te vullen met de namespace-uri van het sectormodel, hetzij het element namespace te vervangen door de elementen <code> en <versie> die gevuld worden met de code en versie van het sectormodel. Het komt er dan zo uit te zien:
<entiteittype>
<code>BG</code>
<versie>0310</versie>
<naam>LIG</naam>
</entiteittype>
Mijn voorkeur gaat uit naar deze laatste variant, omdat die goed leesbaar en eenvoudig te begrijpen is.
Bij deze (zie bijlage) de uitwerking van RFC0391.
Bijlage
Tijdens de StUF Expertgroep van 19 oktober 2016 is dit RFC nogmaals behandelt. We hebben nl. over het hoofd gezien dat er in de stuurgegevens een 'entiteittype' element voorkomt. Deze kunnen we echter niet in de namespace van het sectormodel plaatsen. Henri heeft hiervoor daarom een oplossing uitgewerkt dat vervolgens door Maarten is aangescherpt.
Een andere optie, het verwijderen van dit element uit de stuurgegevens, is niet haalbaar omdat foutafhandeling uitgaat
van de huidige content van de stuurgegevens.
Sid stelt voor om de elementnaam 'code' te vervangen door 'sectormodel'. Tevens wordt voorgesteld 'naam' te vervangen door 'type'. De StUF Expertgroep gaat akkoord met het voorstel met de daarop aangebrachte wijzigingen.
De voorgestelde wijzigingen kunnen in de voorgaande post worden terug gevonden.
Tijdens de StUF Expertgroep van 16 november 2016 is besloten de uitwerking van dit RFC goed te keuren.