Implementatie en versionering
De Standaard Officiële Publicaties bestaat uit twee delen:
- het informatiemodel van de standaard in UML en tekst; dit beschrijft de informatie-klassen en hun onderlinge samenhang
- een Implementatiemodel Officiële Publicaties (IMOP) van STOP, dat beschrijft hoe de informatie uit de standaard geserialiseerd moet worden naar uitwisselbare XML.
Deze twee delen kennen elk verschillende versies. Op deze pagina wordt de samenhang tussen standaard, implementatiemodel, serialisatie en de verschillende versies daarvan beschreven.
Elke versie van de Standaard Officiële Publicaties (STOP) definieert
- alle soorten modules en de samenhang daarvan binnen het informatiemodel; de inhoud van een module is de uit te wisselen informatie
- de bedrijfsregels die de samenhang tussen de modules inperkt, beperkingen stelt aan toegestane waarden van informatie in de module, en andere eisen waaraan de informatie moet voldoen.
Elke versie van de standaard wordt geïmplementeerd middels één of meer versies van het Implementatiemodel Officiële Publicaties (IMOP). Een IMOP-versie bestaat uit een set hulpmiddelen die beschikbaar worden gesteld om de beschreven informatie, geserialiseerd als XML, te maken, te valideren en uit te wisselen:
- schema's (XSD's) leggen de structuur van de modules in XML vast
- schematrons implementeren bedrijfsregels waarmee gevalideerd kan worden of de geserialiseerde informatie voldoet aan de bedrijfsregel. Niet alle bedrijfsregels kunnen in een schematron worden vastgelegd
- transformaties (XSLT's) om de serialisaties van de ene naar de andere IMOP-versie over te zetten, als mogelijk
Voor dezelfde versie van STOP kunnen meerdere versies van IMOP uitgebracht worden. In een nieuwe versie van IMOP zijn de hulpmiddelen verbeterd: schema's zijn gestroomlijnd, validaties zijn aangescherpt en er zijn wellicht fouten uitgehaald. Alle versies van IMOP die bij dezelfde versie van STOP horen, worden gemaakt voor hetzelfde informatiemodel en voor dezelfde bedrijfsregels.
Opeenvolgende STOP-versies zullen de standaard in het algemeen niet volledig op zijn kop zetten. Dat betekent dat zowel het informatiemodel als de bedrijfsregels voor een specifieke module in opeenvolgende versies van de standaard identiek kunnen zijn. Er is dan sprake van dezelfde modelversie voor de module, en dus ook van dezelfde wijze van serialiseren van de module. Er is één serialisatiewijze voor één moduleversie.
Elke IMOP-versie legt de beschikbare modelversies vast in een (cumulatief) overzicht: de "versionering van de serialisaties". Dit overzicht geeft alle serialisatie-versies van alle modules uit alle bekende en nog ondersteunde versies van de standaard, ook de preview- of "release candidate"-STOP-versies. Dit overzicht wordt zelf geserialiseerd als XML en uitgeleverd als onderdeel van een IMOP-versie.
Bij elke versie van (de serialisatie van) een versie van een module wordt vastgelegd in welke versie van de standaard deze is geïntroduceerd. Daarnaast wordt verwezen naar de meest recente versie van de hulpmiddelen die gebruikt kunnen worden om de serialisatie te maken en valideren. In latere versies van het implementatiemodel kunnen een nieuw schema en/of nieuwe schematrons voor een bestaande modelversie geleverd worden. Die moeten gezien worden als verbeterde versies van de eerdere schema/schematrons. Een serialisatie van informatie die conform het informatiemodel en de bedrijfsregels van de modelversie is opgesteld zal valide zijn volgens de nieuwe schema's en schematrons. Een serialisatie van informatie die niet (helemaal) voldoet aan het informatiemodel en de bedrijfsregels van de modelversie kan door de eerdere schema/schematrons als valide aangemerkt worden, maar door de nieuwe versies als niet-valide gezien worden.
De moduleversie in het cumulatieve overzicht van modules bevat voor een aantal modules ook informatie om de geserialiseerde inhoud van een module die is opgesteld voor de ene moduleversie geautomatiseerd te transformeren naar (een serialisatie van) hetzelfde type module die voldoet aan een andere moduleversie.
Een transformatie wordt alleen vermeld als het denkbaar is dat zo'n transformatie mogelijk is. Als voor zo'n transformatie altijd aanvullende informatie van buiten de module nodig is, of als er keuzes gemaakt moeten worden die niet te automatiseren zijn, dan zal geen transformatie vermeld worden. Maar ook als er wel een transformatie denkbaar is, kan blijken dat de specifieke inhoud van een module niet om te zetten is; de transformatie zal dan falen.
Het kan zijn dat er wel een transformatie mogelijk is die valide is volgens de hulpmiddelen (schema's/schematrons) van de andere versie, maar die misschien niet voldoet aan alle richtlijnen van de andere versie. In dat geval wordt de uitkomst van de transformatie als Naar beste kunnen gemarkeerd. Dit is het best uit te leggen met een voorbeeld:
- Stel dat A een serialisatie is die gemaakt is conform IMOP versie 1.0.0. In A worden de elementen div en par gebruikt. Het verschil tussen de twee elementen is de manier waarop de inhoud ervan wordt weergegeven. De standaard bevat richtlijnen wanneer een div gebruikt moet worden en wanneer een par. Dat hangt af van de inhoud die in een van deze elementen wordt vastgelegd, en dat is door software niet te bepalen. Het is de mens die de afweging moet maken.
- In STOP v2.0 worden aanvullende richtlijnen opgenomen wanneer div en par gebruikt moeten worden. Vaak zullen div en par op dezelfde manier gebruikt worden in STOP 1.0 en in STOP 2.0, maar in STOP 2.0 zal soms div gebruikt worden waar in STOP 1.0 nog par werd gebruikt.
- Stel dat de informatie die in A is vastgelegd zodanig is dat volgens de richtlijnen van STOP 2.0 (en IMOP 2.0.0) wordt geserialiseerd, daar niet A uitkomt maar B, waarbij op sommige plaatsen div gebruikt is in plaats van par.
- Omdat het de mens is die de afweging tussen het gebruik van div en par moet maken, is het niet mogelijk om een transformatie te schrijven die A omzet in B. Maar dat zou betekenen dat het niet mogelijk is kennis te nemen van de inhoud van A als software alleen IMOP v2.0.0 ondersteunt.
- Omdat het verschil tussen div en par alleen de weergave is, heeft het toch meerwaarde om een transformatie aan te bieden. Deze transformatie laat de twee elementen ongewijzigd en voldoet daarmee niet aan de richtlijnen van STOP 2.0, maar komt er wel dicht bij in de buurt. De uitkomst van de transformatie wordt als Naar beste kunnen gemarkeerd om aan te geven dat het resultaat niet helemaal correct is.
Elementen
Bedrijfsregel | |||
---|---|---|---|
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Code | string | 0..1 |
Unieke code voor een bedrijfsregel Implementatie: br:code |
Implementatiemodel Officiële Publicaties | |||
---|---|---|---|
Beschrijving | Het Implementatiemodel Officiële Publicaties (IMOP) beschrijft hoe de informatie zoals in de standaard (STOP) beschreven is, in XML geserialiseerd moet worden zodat het uitgewisseld kan worden. Bij elke nieuwe versie van de standaard (STOP) hoort een nieuwe versie van het implementatiemodel (IMOP) waarin de serialisatie wordt beschreven en de eisen die daaraan gesteld worden. Van IMOP kan daarna een nieuwe versie verschijnen waar bijvoorbeeld schema's zijn gestroomlijnd, validaties zijn aangescherpt, nieuwe transformaties zijn opgenomen en/of fouten uit de implementatie zijn hersteld. Een nieuwe versie van IMOP beschrijft in principe nog steeds dezelfde serialisatie, dat wil zeggen: een serialisatie van informatie die voldoet aan het informatiemodel en bedrijfsregels uit de standaard, voldoet aan alle schema's en schematrons uit elke versie van IMOP die bij dezelfde versie van de standaard hoort. |
||
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Implementatieversie | versienummer | 1..1 |
Het versienummer van het Implementatiemodel Officiële Publicaties (IMOP) waarmee de XML-serialisatie is gemaakt. Het versienummer voldoet aan de semver standaard. De algemene vorm is major.minor.patch-label, waarbij het label gedeelte optioneel is en voor elke major.minor versie hooguit één versie met een label bestaat. De |
Moduleversie | |||
---|---|---|---|
Definitie | Een versie van de definitie van een module in de standaard. Dit is een combinatie van het informatiemodel voor de module en alle relevante bedrijfsregels. Er ontstaat een nieuwe versie van de module in de standaard als het informatiemodel wijzigt en/of als de bedrijfsregels, invulinstructies etc veranderen. |
||
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Introductieversie | major.minor.label | 1..1 |
De versie van de standaard (STOP) waarbij de versie van de module voor het eerst de vorm heeft zoals door het informatiemodel en relevante bedrijfsregels is beschreven. |
Moduleversie transformatie | |||
---|---|---|---|
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Transformatie | URL | 1..1 |
Internet-adres dat gebruikt kan worden om de transformatie (als XSLT) op te halen Implementatie: sv:locatie |
Introductieversie | major.minor-label | 1..1 |
De versie van het implementatiemodel (IMOP) waarbij de serialisatie van de module voor het eerst de vorm heeft zoals door de versieinformatie is beschreven. Implementatie: sv:introductieversie |
Schema | |||
---|---|---|---|
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Namespace | string | 1..1 | |
Beschikbaar op | URL | 1..1 |
Internet-adres dat gebruikt kan worden om het schema (als XSD-bestand) op te halen. Het XSD-bestand bevat de formele definities voor de XML-implementatie van het informatiemodel. Implementatie: sv:schema |
Schematron | |||
---|---|---|---|
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Beschikbaar op | URL | 1..1 |
Internet-adres dat gebruikt kan worden om de schematron (als SCH-bestand) op te halen Implementatie: sv:schematron |
Serialisatie | |||
---|---|---|---|
Beschrijving | STOP biedt voor elke Module een voorschrift hoe de informatie in de module geserialiseerd moet worden als onderdeel van data uitwisseling. Die specificaties vormen geen onderdeel van het informatiemodel, maar het informatiemodel verwijst wel naar de documentatie ervan. |
||
Generalisatie van | Manifestation identificatie (entiteit) | ||
Zie ook | Instrument en instrumentversies (onderwerp) | ||
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Implementatieversie | versienummer | 1..1 | |
NaarBesteKunnen | bool | 0..1 |
Indien true: geeft aan dat de serialisatie van de module weliswaar technisch voldoet aan de eisen die gesteld worden door het implementatiemodel (IMOP), maar mogelijk niet aan alle richtlijnen die in de standaard aan de module gesteld worden. Dit attribuut wordt aan de serialisatie toegevoegd als de serialisatie is ontstaan uit een (geautomatiseerde) transformatie van de ene naar de andere versie van een module, waarbij de relevante invulinstructies of andere richtlijnen verschillend zijn in beide versies. Een mens zou de transformatie wellicht anders hebben uitgevoerd door de informatie uit de ene serialisatie op een andere manier te modelleren (conform de andere richtlijnen) en dat opnieuw te serisaliseren. |
Serialisatie moduleversie | |||
---|---|---|---|
Definitie | De beschrijving van (de serialisatie van) een versie van een moduledefinitie. De serialisatie blijft in opeenvolgende IMOP-versies ongewijzigd. |
||
Implementatie | sv:Moduleversie | ||
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Naam | string | 1..1 |
De naam (localName) van het XML-element waarmee de module in de serialisatie wordt gerepresenteerd. |
Namespace | string | 1..1 | |
Introductieversie | major.minor-label | 1..1 |
De versie van het implementatiemodel (IMOP) waarbij de serialisatie van de module voor het eerst de vorm heeft zoals door de versieinformatie is beschreven. Implementatie: sv:introductieversie |
Schema | URL | 1..1 |
Internet-adres dat gebruikt kan worden om het schema (als XSD-bestand) op te halen. Het XSD-bestand bevat de formele definities voor de XML-implementatie van het informatiemodel. Implementatie: sv:schema |
Schematron | URL | 0..* |
Internet-adres dat gebruikt kan worden om de schematron (als SCH-bestand) op te halen Implementatie: sv:schematron |
Standaard Officiële Publicaties | |||
---|---|---|---|
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Standaardversie | major.minor-label | 1..1 |
De versie van de standaard. Het versienummer voldoet aan de semver standaard. De algemene vorm is major.minor.0-label, waarbij het label gedeelte optioneel is en voor elke major.minor versie hooguit één versie met een label bestaat. |
Transformatie | |||
---|---|---|---|
Definitie | Een beschikbare transformatie om de serialisatie van een module die conform de beschreven serialisatievoorschriften is gemaakt om te zetten naar de serialisatie van dezelfde module conform een andere serialisatieversie. Dit is dus een omzetting van een module die is gemaakt volgens een bepaalde moduleversie naar een andere moduleversie. |
||
Implementatie | sv:Transformatie | ||
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Beschikbaar op | URL | 1..1 |
Internet-adres dat gebruikt kan worden om de transformatie (als XSLT) op te halen Implementatie: sv:locatie |
Versionering serialisatie | |||
---|---|---|---|
Beschrijving | Beschrijving van alle versies van de serialisatie van alle modules uit alle gepubliceerde, nog ondersteunde versies van het Implementatiemodel Officiële Publicaties (IMOP). |
||
Eigenschappen | Type | Kardinaliteit | Beschrijving |
Hoogst bekende versie | versienummer | 1..1 |
De hoogste/grootste versie van de implementatie van de standaard waarvan de informatie in dit overzicht is meegenomen. Dat kan een preview/release candidate versie zijn. Het overzicht bevat versieinformatie uit alle versies van (de implementatie van) de standaard voor zover ze nog ondersteund worden. |