In de XML-Schema's van StUF is d.m.v. het 'version' attribute te zien welke versie van het schema het betreft.
Het is op dit moment echter niet mogelijk om aan/in een StUF XML-schema te zien bij welke patch het schema hoort en in welke patch de laatste wijziging in het schema is aangebracht terwijl die gegevens volgens mij toch veel informatiever zijn.
Het zou handig zijn om wel over deze informatie te kunnen beschikken omdat op die manier in een schemaeditor in 1 oogopslag is te zien of met de juiste versie van het schema wordt gewerkt.
Ook kunnen daarmee op een handige wijze applicaties automatisch worden voorzien van patchversie informatie waardoor wederom in 1 oogopslag te zien is welke versie van een StUF sectormodel of onderlaag door een applicatie ondersteund wordt.
We zouden deze informatie graag aan de schema's toevoegen.
Hiervoor zijn enkele mogelijkheden:
Voeg aan het 'xs:schema' element in de XML-Schema's de attributen 'StUF:patch' en 'StUF:laatstePatchGewijzigd' toe.
Voeg als eerste element aan het 'xs:schema' element 'xs:annotation/xs:appinfo' toe met daarin de elementen 'patch' en 'laatstePatchGewijzigd'.
Natuurlijk zijn de namen van de attributen en elementen voorstellen en zijn betere voorstellen altijd welkom.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0144.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Mijn voorkeur gaat uit naar variant 2 en ik zie geen redenen, waarom we dit niet nu al zouden kunnen invoeren. Het heeft per slot van rekening geen consequenties voor de berichten.
In de StUF Expertgroep van 19-11-2014 heeft Henri Korver 2 alternatieven gepresenteerd (zie bijlage). Uiteindelijk heeft de StUF Expertgroep gekozen voor het tweede alternatief, het alternatief met de expliciete structuur. Daarnaast heeft de StUF Expertgroep vastgesteld dat alle schema's binnen een patch van nieuwe patch informatie moet worden voorzien.
Onderhoudsverzoek is overigens omgezet naar een erratum (ERR0353).
Bijlage
Ter voorbereiding op de komende patch (1 april 2015) ben ik aan de gang gegaan om de gevraagde wijziging in de schema's door te voeren. Daarbij liep ik tegen twee issues aan.
Kan iedereen zich hierin vinden?
Dat zou betekenen dat voortaan toch voor zowel de onderlaag als voor elk sectormodel een nieuwe patch uitgebracht moet worden. Het zou immers vreemd zijn als de schema’s van de onderlaag in de zip van de onderlaag andere patchinformatie hebben dan de schema’s van de onderlaag in de zip van de sectormodellen. De vraag is of dit is wat we willen?
Bijlage
Het gaat mij (veel) te ver dat de onderlaag moet worden gepatcht als er een sectormodel wordt gepatcht. Wat mij betreft beperken we dit tot alle bestanden binnen het (sector-) model. Anders zou je bij een patch op ZKN ook meteen een 'patch' op de onderlaag én op BG moeten doen.
En hoe moeten andere beheerders van sectormodellen hiermee om gaan als zij dezelfde werkwijze willen hanteren? Moeten die dan ook de files van de onderlaag een nieuwe versie geven?
Mij lijkt het dat alle bestanden binnen een map uit de zip-file van een patch (mappen op het hoogste niveau) dezelfde patchinformatie moeten hebben en niet alle bestanden van de zip-file. Dat lijkt me bijna onbeheersbaar. De aanleiding voor de uitspraak is dat je in elke file kunt zien welke patch-versie van het model je hebt. Dit kunnen we natuurlijk gemakkelijk beperken tot elke file in het model zelf en niet elke file in het zip-bestand.
Tijdens de StUF Expertgroep van 18 februari 2015 is besloten om de appinfo structuur enigszins aan te passen.
Het element 'sectormodel' wordt gewijzigd in 'onderdeel' dat wordt gevuld met de namespace van het betreffende onderdeel. Daarnaast is de structuur ook van toepassing verklaard op WSDL bestanden. Elk schema en WSDL bestand binnen bijv. het sectormodel bg0310 krijgt dus de volgende appinfo structuur:
<appinfo>
<StUF:onderdeel>http://www.egem.nl/StUF/sector/bg/0310</StUF:onderdeel>
<StUF:patch>nn</StUF:patch>
<StUF:patchdatum>jjjjmmdd</StUF:patchdatum>
<StUF:schemaversie>nn</StUF:schemaversie>
</appinfo>
Verder is besloten om voor elk onderdeel de mogelijkheid open te houden om een aparte 'patch' en 'patchdatum' waarde in te vullen. Een wijziging in de bg0310 schema's betekent dus niet automatisch dat de appinfo structuur voor de StUF onderlaag wordt aangepast.
De in deze discussie gemaakte afspraken moeten nog gedocumenteerd worden in de best practices.
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0403.
De lijst met onderhoudsverzoeken vind je op:
www.wikixl.nl/wiki/basisgemeente/index.php/StUF-Expertgroep#Documenten
In de bijgaande pdf vind je de pagina die ik n.a.v. ONV0403 heb toegevoegd aan de best practices.
Bijlage
Deze tekst roept nog twee vragen bij me op:
Behoren stuf0301.xsd en de andere stuf0301 schema's en wsdl's tot het onderdeel met de stuf0301 namespace?
Behoren gegeven de nieuwe best practise voor de opdeling van sectormodellen de schema's met de basisentiteiten te zamen tot een apart onderdeel met de namespace van het sectormodel en behoren de schema's en wsdl's van de diverse koppelvlakken weer in een apart onderdeel met de namespace van het koppelvlak?
Bij deze de antwoorden:
Het schema 'stuf0301.xsd', de andere stuf0301 schema's en wsdl's behoren dus tot het onderdeel 'StUF 3.01 onderlaag' dat geïdentificeerd wordt met de namespaceidentifier 'http://www.egem.nl/StUF/StUF0301'.
De schema's met de basisentiteiten behoren inderdaad tot een apart onderdeel met de namespace van het sectormodel en de schema's en wsdl's van de diverse koppelvlakken inderdaad tot aparte onderdelen met de namespace van het koppelvlak.
Dit is inderdaad redelijk wat werk hoewel het mij in patch 23 niet tegenviel.
Het lijkt me goed om een en ander ook te verduidelijken in de best practise.
Bij deze het gewijzigde voorstel waarin alleen de nieuwe passages gerenvooieerd zijn.
Bijlage
In het vooorstel staat in de 5de alinea (codevoorbeeld als alinea geteld): "Voor de XML-schema en wsdl bestanden die voor het eerst geïntroduceerd worden heeft dit element de waarde '00'."
Dit lijkt er in mijn ogen op dat als er een xds-bestand wordt toegevoegd aan een onderdeel, dat dit ene bestand dan een 0 heeft in het patch-element. Dat lijkt me niet consistent met de verdere tekst die stelt dat binnen een onderdeel alle files dezelfde patch-waarde hebben. Waarschijnlijk wordt bedoeld dat voor nieuwe StUF-onderdelen (in xsd's herkenbaar door een eigen waarde voor element <StUF:onderdeel>) de waarde 0 is.
Een goede aanscherping. Ik bedoel inderdaad dat in de XML-Schema en wsdl bestanden van de eerste versie van een onderdeel het element 'patch' de waarde '00' heeft. Ik heb een aangepast voorstel bijgevoegd.
Bijlage
Tijdens de StUF Expertgroep van 17 februari 2016 is het voorstel goedgekeurd. Het onderhoudsverzoek is omgezet naar een erratum (ERR0403).