De huidige ontwikkelingen op het gebied van de vernieuwde StUF-standaarden hebben ertoe geleid het beheer-proces van de standaarden en de tooling die gebruikt wordt voor de totstandkoming van de standaarden ook een vernieuwing zal ondergaan. Ten eerste zal het aantal te ontwikkelen en dus ook te beheren standaarden in de nabije toekomst sterk gaan groeien. De nadruk wordt daarbij gelegd op de eindproductstandaarden, de koppelvlakken dus. De huidige manier van ontwikkelen en beheren van de standaarden is niet afdoende om het in de toekomst gewenste tempo bij te kunnen benen Het proces voor het ontwikkelen en beheren van de standaarden moet dus zo ingericht en ondersteund worden dat dit sneller kan, zonder dat de kwaliteit wordt aangetast. Sterker nog, we willen zelfs de kwaliteit van de standaarden verbeteren.
Naast deze ontwikkelingen t heeft het SIG rapport van de gemeente Den Haag ons duidelijk gemaakt dat de standaarden beter moeten aansluiten bij de praktijk van code-generatie. De standaarden moeten eenvoudiger implementeerbaar zijn. Dat geldt niet alleen voor de uit die standaarden voortkomende berichten maar ook voor de opzet van de XML-Schema’s waarmee die berichten worden vormgegeven.
Om die nieuwe aanpak te realiseren is er door KING intern een pilot opgestart. Bij de opzet van een nieuw proces in de pilot gaan we er vanuit dat de XML-Schema’s niet meer handmatig in elkaar worden gezet maar dat deze vanuit de informatiemodellen worden gegenereerd. In dat proces moeten vele keuzes en inrichtingsvraagstukken worden beantwoord.
Een van de keuzes die we moeten maken bij het genereren van XML-Schema’s is of we gebruik gaan maken van globale of juist alleen van lokale complexTypes. Dit is essentieel aangezien het genereren van globale complexTypes de programmatuur voor het genereren van de XML-Schema’s aanzienlijk complexer maakt.
Eerder werd vanuit enkele leveranciers al aangedrongen op het behouden van de halffabricaten. De XML-Schema’s van StUF-BG, StUF-ZKN en StUF-ZTC dus. Enkele leveranciers hebben hun code-base namelijk gebaseerd op deze halffabricaten. Dit zou je kunnen interpreteren als het gebruiken van globale complexTypes. Tijdens de StUF Expertgroep van april 2016 werd echter bij de bespreking van onderhoudsverzoek ONV0420 (Constructie verschillen berichten mutatie en vraag-antwoord) voorgesteld om in de best practice te beschrijven dat in koppelvlakschema’s geen gebruik moet worden gemaakt van globale complexTypes. Dit zou namelijk grote voordelen opleveren bij code generatie.
Op mijn vraag of dit toch niet vervelend zou zijn aangezien in dat geval bij code-generatie geen hergebruik gemaakt kan worden van de code en er dus veel redundant code gegenereerd wordt gaven enkele aanwezigen aan dat dit naar hun mening helemaal geen probleem is. Er werd zelfs gesteld dat het gebruik van global complexTypes ook tot extra code leidt.
Het moge duidelijk zijn dat als ontwikkelaar van de programmatuur voor het genereren van de XML-Schema’s mijn voorkeur uitgaat naar lokale complexTypes. Leidend hierin is echter niet de complexiteit van de door mij te ontwikkelen programmatuur maar juist de complexiteit van het, op basis van de gegenereerde XML-Schema’s, genereren van de code en de complexiteit van die gegenereerde code.
D.m.v. deze discussie wil ik checken of de in de laatste StUF Expertgroep geuite mening ook door anderen wordt gedeeld. Indien blijkt dat er geen voorkeur is voor globale compexTypes dan zullen de gegenereerde XML-Schema’s geen of in ieder geval een minimum aan globale complexTypes bevatten.
Graag hoor ik hoe de community hierover denkt. Besef daarbij goed dat tussen de beide varianten nog allerlei tussenvormen bestaan. Aan het ene eind van het spectrum de XML-Schema’s waarin alle complexTypes globaal zijn en aan het andere eind de XML-Schema’s waarin alle complexTypes (behalve de complexTypes uit niet StUF schema’s) lokaal zijn met als gevolg dat alle elementen maar ook alle datatypes in de namespace van het koppelvlak staan.
Om jullie in staat te stellen hierover een goed oordeel te vormen heb ik bijgaand een voorbeeld gevoegd van XML-Schema’s met een bericht waarin gebruik gemaakt wordt van globale complexTypes en een voorbeeld van XML-Schema’s met datzelfde bericht waarin gebruik wordt gemaakt van lokale complexTypes. Beide voorbeelden zijn weliswaar gebaseerd op een bericht uit het koppelvlak Documentcreatieservices 1.10 dat gebaseerd is op StUF 3.01 maar ze geven n.m.m. wel een voldoende beeld van de geschetste situaties.
Nog enkele opmerkingen over de voorbeelden. Het Globalized voorbeeld is in feite een met de XSD-Resolver bewerkte versie van het Documentcreatieservices schema met daarin alleen het bericht ‘geefSjabloonIDByZaakType_ZktLa01‘ opgenomen. In het Localized voorbeeld heb ik de complexTypes die in het Globalized voorbeeld globaal stonden zo veel mogelijk lokaal geplaatst. Dit heb ik echter niet volledig doorgevoerd aangezien de hoeveelheid complexTypes en simpleTypes daarvoor gewoon te groot is. Tenslotte is er nog een klein verschil tussen de Globalized en Localized versie. In de Globalized versie bevat het element ‘heeftVerantwoordelijkeOEH’ een recursieve structuur. De ‘gerelateerde’ van dat element bevat een ‘isGehuisvestIn’ wiens ‘gerelateerde’ weer een ‘huisvest’ bevat wiens ‘gerelateerde’ weer een ‘isGehuisvestIn’ bevat. In de Localized versie is de 2e ‘isGehuisvestIn’ weggelaten waardoor de recursie wordt afgebroken. De onmogelijkheid van recursie is overigens een gevolg van een keuze voor lokale complexTypes.
In bepaalde koppelvlakken, zoals bij Zaak- en Documentservices zijn er veel relaties naar (soms keuze uit) dezelfde entiteiten (bijvoorbeeld natuurlijk persoon, niet natuurlijk persoon, medewerker of vestiging). Deze entiteiten komen dus vaak voor in bericht, soms ook met (enige mate van) recursie.
Ook komen entiteiten vaak meerdere keren voor binnen eenzelfde bericht, zoals in een wijzigingsbericht, waarin element object 2x voorkomt. Alle complex typen binnen het object worden in het geval van lokale complex types dus dubbel gedefinieerd.
Bijvoorbeeld in de huidige updateZaak_Lk01 zou dan identiek complex type natuurlijkPersoon 14 keer (2 x 7) gedefinieerd worden. En hetzelfde gebeurt voor medewerker, organisatorisch eenheid, vestiging en niet-natuurlijk persoon, die ook elk 14 keer lokaal worden gedefinieerd.
Het schema (xsd-bestand voor een koppelvlak) kan daardoor erg groot worden.
Sommige complex types worden voor elk bericht identiek gebruikt, zoals stuurgegevens/zender en ontvanger.
Mijn voorkeur zou het dus hebben om wel -binnen een koppelvlak- globale complex types te definiëren. Wel moeten we af van de gelaagdheid van complex types gebaseerd op ander complex type met restricties.
Helemaal zonder globale complex types kunnen we denk ik niet, zoals gml.
Ook bij het overgaan naar koppelvlakken als de eindproductstandaarden blijft voor mij uitgangspunt dat de complexTypes voor StUF-entiteiten in de namespace van het sectormodel blijven bestaan. Er blijven dus definities voor de inhoud van NPS-kennisgeving, NPS-vraagScope, NPS-vraagSelectie, NPS-kerngegevens, NPS-antwoord en nog wel een paar noodzakelijk in de basisschema's van het sectormodel voor de basisgegevens. De link tussen semantiek en berichtinhoud wordt gelegd via de sectormodel namespace. Het wordt heel verwarrend als in een koppelvlak alle elementen zitten in de namespace van het koppelvlak. Hoe weet je dan bijvoorbeeld van een NPS of het gaat om de NPS gedefinieerd in bg0310 of de NPS gedefinieerd in woz0312?
Het sectormodel definieert de maximale omvang van de verschillende entiteiten in de meest voorkomende contexten (kennisgeving, kerngegevens en vraag/antwoord). Bij genereren is het niet langer nodig om te werken met restrictions. Omdat het koppelvlak een eigen namespace heeft en de elementen voor de StUF-entiteiten in deze namespace zitten is het noodzakelijk om te werken met complexTypes om de voor een koppelvlak specifieke invulling van een StUF-entiteit te definiëren.
Voor het genereren van code uit de XSD geef ik de voorkeur aan de globalized versies omdat we dan nog enigzins in staat zijn om code te hergebruiken. De totale gegenereerde code voor de localized versie ook groter dan de globalized versie (in het voorbeeld 44719 regels tov 41290 regels). Als het gaat om het verminderen van de vereiste inspanning om een nieuw koppelvlak (of een nieuwe versie van een bestaand koppelvlak) te realiseren dan kan meer winst behaald worden door niet langer te werken met restrictions, maar alleen extensions te gebruiken.
Vanuit de beheersbaarheid van sectormodellen en koppelvlakken geven wij sterk de voorkeur aan het zo globaal mogelijk definiëren van de ComplexTypes. Wanneer ieder koppelvlak met eigen lokale varianten gaat werken is het risico groot dat uiteindelijk de uniformiteit ver te zoeken zal zijn.
Volgens ons hoeft het zo globaal mogelijk definiëren (en ook afleiden met restricties etc.) het genereren van software etc helemaal niet in de weg te staan.
Dus graag zoveel mogelijk, zo globaal mogelijk.
Het lijkt mij dat de globale versie de enige juiste weg is om de standaard een standaard te laten blijven. Voornamelijk inzake het duidelijk houden wat uit de (gegevens)-standaard wordt hergebruikt en op welke punten het betreffende koppelvlak afwijkt hiervan.
Zoals enkele anderen ook al opmerkten, leidt het gebruik van lokale complex typen tot veel duplicatie in het schema en daarmee ook in de gegenereerde code. Dit leidt bij een implementatie dus ook tot (veel) meer werk.
Onze voorkeur gaat dus uit naar globale complex types, of in ieder geval globaal per koppelvlak.
Het beperken van het gebruik van restricties op complexe typen zal naar verwachting ook een belangrijke bijdrage kunnen leveren aan het verminderen van de benodigde inspanning voor het implementeren van een koppelvlak.