Samenbrengen van conceptuele schema's in één gemeenschappelijke verzamelplek

[ArjanLoeffen]

TLDR: Als we een XML schema willen genereren voor een instelling voegen we daar schema's bij die van elders zijn opgehaald, en lokaal worden bewaard. Dat doet iedereen, waardoor veel lokale kopieën ontstaan. Het is mogelijk die allemaal in één verzamelplek bij elkaar te plaatsen. Beheer wordt daardoor veel simpeler.

Uitwerking:

We hebben nu een constructie waarin per instelling wordt bepaald wat de XML schema's zijn (GML, Xlink, ISO Citations etc.). Deze schema's wordt per instelling beheerd, in:

/Imvertor-Chains/src/main/resources/input/[naam van instelling]/xsd

Doordat veel instellingen gelijke schema's gebruiken worden deze meermaals gedupliceerd. Dat is niet handig en levert potentieel afwijkingen op die niet behoren op te treden. Ook wordt de samenwerking in feite ondermijnd. Iedereen kan zijn/haar eigen ding doen. Bijvoorbeeld: welke constructies horen nu eigenlijk bij een GML 322 profiel?

Het is naar mijn mening mogelijk alle schema's samen met de conceptuele schema's te verzamelen in één verzamelplek (gewoon binnen dit GIThub project), waarnaar dan vanuit alle instellingen kan worden verwezen. Er treedt dan geen duplicatie meer op.

Een voorbeeld van de huidige situatie:

• Kadaster maakt gebruik van GML322.
• Het conceptuele schema en de mapping zit in '/input/Kadaster/xsd/conceptual-schemas.xml'.
• Het bijbehorende XML schema (voor de Kadaster en ISO19136 schema samensteller) staat in /input/Kadaster/xsd/www.opengis.net/GML322-20160101/gml/3.2.2

Nieuwe situatie:

• Kadaster maakt functioneel op dezelfde manier gebruik van GML322.
• Een referentie naar het conceptuele schema en de mapping zit in '/input/Kadaster/xsd/conceptual-schemas.xml'.
• Het bijbehorende XML schema (voor de Kadaster en ISO19136 schema samensteller) staan in /cs/xsd/www.opengis.net/GML322-20160101/gml/3.2.2
• De nieuwe folder /cs (= verzamelplek) bevat alle conceptuele schema's, mappings, en XML schema's die nodig zijn voor het samenstellen van complete producten. (Dat kan zelfs uitgebreid worden in de toekomst.)

Effect op bestaande werkwijze:

1. Aanpassingen aan de XML schema's doen we in de verzamelplek
2. Aanpassingen aan de conceptuele schema's doen we in de verzamelplek
3. De conceptual schema's van de instellingen bevatten alleen nog referenties naar conceptual schemas en maps in de repository (via xinclude).

Graag reactie, ik zal er ook achteraan gaan omdat we voor een IHW schema opdracht zitten.

[ArjanLoeffen]

Nb. komt in essentie neer op
1/ aanpassing van /Imvertor-Chains/src/main/resources/cfg/XsdCompiler/parms.xml:

<EXTERNAL_XSD_FOLDER>${system/inp-folder-path}/xsd</EXTERNAL_XSD_FOLDER>
wordt
<EXTERNAL_XSD_FOLDER>${system/managedinstallfolder}/cs</EXTERNAL_XSD_FOLDER>

2/ het verplaatsen van alle lokale folders
3/ het opdelen van alle conceptual schemas naar de nieuwe locaties, en het plaatsen van de nodige xinclude verwijzingen.

[kad-mesdat]

Nog wat vragen:

1. Onze modelleurs merken hier niets van bij het genereren toch? Dit gaat over de organisatie binnen het imvertor project.
2. Daar waar hierboven instelling genoemd wordt is dat in de betekenis van "setting" en niet Kadaster of VNG oid.
3. Hoe doen we het dan met settings die afwijken? (Vermoeden: die wijzen naar het afwijkende conceptual schema in de ../cs/.. directory)
4. Geldt het alleen voor conceptual schemas zoals GML, measure enz.

[ArjanLoeffen]

1. Modelleurs merken niks. Het resultaat van deze verandering is onzichtbaar, het betreft alleen een aanpassing in de configuratie.
2. Instelling is: Kadaster, IHW, Geonovum, BRO, Waarderingskamer. Deze zullen de aanpassen financieren (besluit dd. 26 sept 2022).
3. Ja: Wanneer je afwijkt van de gemeenschappelijke configuratie, dan maak je je eigen conceptueel schema en mogelijk je eigen XML schema "folder"
4. Het geldt voor alle conceptuele schema's zoals we die nu kennen.

[ArjanLoeffen]

In de laatste UG is vastgesteld dat dit kan worden doorgevoerd; iedereen heeft akkoord gegeven voor financiering.

[ArjanLoeffen]

Is er nog iemand die GML 3.2.1 gebruikt (en dus niet GML 3.2.2 of een profiel daarvan) in een Imvertor run?

[HanWelmer]

BRO gebruikt momenteel GML 3.2.1. Maar op basis van het document "07-036r1_Geography_Markup_Language_3.2.2_corrigendum" zie ik geen problemen om te upgraden naar GML 3.2.2.

[ThiesMesdag]

Het Kadaster is volgens mij helemaal over op 3.2.2. Of zou dat moeten zijn.

[wilkoquak]

Is er nog iemand die GML 3.2.1 gebruikt (en dus niet GML 3.2.2 of een profiel daarvan) in een Imvertor run?

Omdat het 3.2.2 xsd in de 3.2.1 map staat op de GML schema downloadpagina en het xsd in de namespace 3.2 rondhangt is de vraag niet hemelaal helder. Door deze verwarring weet volgens mij niemand precies wat je bedoelt en is het wat mij betreft OK om de meest recente versie (=3.2.2) te pakken. Overigens zou het wellicht logischer zijn om te zeggen dat we GML 3.2 gebruiken en dan altijd de meest recente te pakken.

[melsk-r]

Zie #309.