In de huidige bg0310-schema's worden alle elementen en relaties van het supertype (bijv. SUB en RPS) handmatig platgeslagen (gedupliceerd) in de subtypen (bijv. NPS, NNP en VES). Daarbij worden de subtypen met een choice in het supertype opgenomen. Bovendien worden er ook nog een aantal afleidbare gegevens aan het supertype toegevoegd om het supertype geschikt te maken voor bevragingen over subtypen heen.
Mijn voorstel is om in de nieuwe schema's voor StUF-BG subtypering niet meer te modelleren door het plat te slaan maar hiervoor het bekende extension-mechanisme te gebruiken van XML Schema (XSD). Mijn voorkeur gaat uit naar XSD-extension om de volgende redenen:
- Compactere schema’s, elementen uit het supertype worden niet meer gedupliceerd naar de suptypen.
- De inheritance-structuur blijft doormiddel van het extension mechanisme gehandhaafd in het schema. Codegeneratoren kunnen deze structuur doorgeven aan de gegenereerde software libraries
- Geen aanpassingen nodig aan het UGM-model. UGM behoudt haar elegante overervingsstructuur.
- UGM is beter te onderhouden omdat er geen elementen en relaties van het supertype hoeven te worden gedupliceerd in de subtypen.
- Last, but not least: het schema-algoritme is al zo geïmplementeerd
Het werken met XSD-extension heeft wel als nadeel dat je niet in alle gevallen de volgorde kunt bepalen van elementen en relaties in de schema's en berichten. Immers de elementen die via extension vanuit de supertypen worden overgeërfd naar de subtypen komen altijd als eerst in de sequentie. Gezien de hierboven genoemde voordelen, neem ik dit nadeel voor lief.
In de bijlage heb ik een extract van de basisschema's gegenereerd voor SUB, PES, NPS, NNP en VES voor de nieuwe StUF-BG 3.20. Deze schema's zijn nog niet bedoeld voor algehele review maar alleen om hier het XSD-extension mechanisme uit te leggen. In de gegenereerde schema's is het -abstract type een -basis type waar alleen het "entiteittype" attribute is verwijderd. Dit is noodzakelijk om extension mogelijk te maken naar de subtypes. In de subtypes wordt het entiteittype attribute uiteindelijk weer toegevoegd met een concrete waarde.
In deze versie van de schema's is het -abstract type gedefinieerd als een restriction op een -basis type. Waarschijnlijk is het beter om het -basis type als een extension op het -abstract type te definiëren. Dat passen we naderhand aan want ik moet eerst weten wat jullie überhaupt van deze nieuwe werkwijze vinden?
Bijlage
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0463.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 16 november 2016 is besloten dit RFC goed te keuren. Wel moet er nog worden gekeken wat in verband hiermee het gebruik van choices voor consequenties heeft.