Probleem
Binnen de schema's van StUF-BG 3.10 en StUF-ZKN 3.10 komen op diverse plaatsen choice content model constructies voor binnen andere choice content model constructies.
In sommige gevallen zijn deze constructies nutteloos en leiden ze zelfs tot verwarring. Een voorbeeld daarvan vind je binnen het element 'bagAGO_Lk03' in het schema 'bg0310_msg_bag.xsd'. De diepste choice voegt daar niets toe.
Een ander voorbeeld waar ik mijn vragen bij stel is de choice in choice constructie binnen de complexType 'OBJ-basis' in het schema 'zkn0310_ent_basis.xsd'. Daar is de diepste choice optioneel en heeft een cardinaliteit van maximaal 31. Dat is exact gelijk aan het aantal elementen binnen die choice. Dat doet me vermoeden dat men hier de mogelijkheid wil scheppen dat alle elementen optioneel moeten zijn. Ik kan me niet voorstellen dat men hier de mogelijkheid wil scheppen om 31 keer achter elkaar het element 'gemeente' of 'status' te plaatsen. Indien dat klopt dan was hier een sequence met optionele elementen beter op zijn plaats geweest.
Oplossing
Inventariseer de choice in choice constructies en verwijder ze daar waar ze niets toevoegen of vervang ze daar waar ze verwarren en onnodig complex zijn.
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR287.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 18 februari 2015 is aangegeven dat dit issue zich voordoet bij het restricten van een complexType. In de bron complexType is de constructie wel correct. De constructie ziet er volgens enkele leden van de StUF Expertgroep wel erg vreemd uit en is niet meer uit te leggen. Er is geconcludeerd dat het toch handig is om hier een keer naar te kijken en het probleem op te lossen.
Ik heb nog eens goed gekeken naar de choice in choice constructies en op de plaatsen waarop ik doel is er geen sprake van dat het probleem zich voordoet n.a.v. het restricten van een complexType. Ik heb even geïnventariseerd waar het zich voordoet en waar dit n.m.m. vreemd is.
bagAGO_Lk03, bagAGO_Lk04, bagAOC_Lk03, bagAOC_Lk04, bagBN_Lk03, bagBN_Lk04, bagCOR_Lk03, bagCOR_Lk04, bagHER_Lk03, bagHER_Lk04, bagIO_Lk03, bagIO_Lk04, bagIN_Lk03, bagIN_Lk04, bagMUT_Lk03, bagMUT_Lk04, bagOA_Lk03, bagOA_Lk04, bgrBIG_Lk03, bgrBIG_Lk04, bgrBSLSP_Lk03, bgrBSLSP_Lk04, bgrBSLLP_Lk03, bgrBSLLP_Lk04, bgrCOG_Lk03, bgrCOG_Lk04, bgrIBV_Lk03, bgrIBV_Lk04, bgrISLLP_Lk03, bgrISLLP_Lk04, bgrISLSP_Lk03, bgrISLSP_Lk04, bgrISV_Lk03, bgrISV_Lk04, bgrKVO_Lk03, bgrKVO_Lk04, bgrMAB_Lk03, bgrMAB_Lk04, bgrMGB_Lk03, bgrMGB_Lk04, bgrMGS_Lk03, bgrMGS_Lk04, bgrOABSV_Lk03, bgrOABSV_Lk04, bgrSSVSAMEN_Lk03, bgrSSVSAMEN_Lk04, bgrSSVSPLITS_Lk03, bgrSSVSPLITS_Lk04, bgrVB_Lk03, bgrVB_Lk04, bgrVBI_Lk03, bgrVBI_Lk04, bgrVBN_Lk03, bgrVBN_Lk04, bgrVOCDEEL_Lk03, bgrVOCDEEL_Lk04, bgrVOCHEEL_Lk03, bgrVOCHEEL_Lk04, braGHO_Lk03, braGHO_Lk04, braHNU_Lk03, braHNU_Lk04, braHOB_Lk03, braHOB_Lk04, braHOR_Lk03, braHOR_Lk04, braHWP_Lk03, braHWP_Lk04, braOHN_Lk03, braOHN_Lk04, braWGW_Lk03 en braWGW_Lk04
Daar heeft het volgend mij echter nergens een toegevoegde waarde.
Ook binnen het schema 'zkn0310_ent_basis.xsd' komen choice in choice constructies voor die wat vreemd ogen.
Het zou me niet verbazen als in al deze complexTypes slechts 1 van alle elementen gebruikt mag worden. In dat geval zou de choice geëlimineerd kunnen worden waardoor er een begrijpelijker model ontstaat.
Als we de complexType 'OBJ-kerngegevens' erbij betrekken, een restriction van OBJ-basis, dan kan het dat het verhaal toch anders is. Hier is de choice namelijk noodzakelijk om er voor te kunnen zorgen dat er maar 1 element in de kerngegevens kan worden opgenomen.
De vraag is echter of de cardinaliteit van de choice in OBJ-basis echt 31 moet zijn. Als deze daar ook al op 1 gesteld kan worden dan kan de tweede choice geëlimineerd worden in zowel de basis als in de restriction.
In het schema 'zkn0310_ent_mutatie.xsd' komen in de compelxTypes 'BTR-kerngegevensKennisgeving', 'BTR-subtypeMDWOEH-kerngegevensKennisgeving' en 'OBJ-kerngegevensKennisgeving' en in het schema 'zkn0310_ent_vraagAntwoord.xsd' de complexTypes 'BTR-gerelateerdeAntwoord', 'BTR-gerelateerdeVraagScope', 'BTR-subtypeMDWOEH-gerelateerdeAntwoord', 'BTR-subtypeMDWOEH-gerelateerdeVraagScope', 'OBJ-gerelateerdeAntwoord' en 'OBJ-gerelateerdeVraagScope' voor. Deze zijn gerelateerd aan de complexTypes die in bullet 2 zijn besproken.
Wijzigen van bestaande sectormodellen is ongewenst. Er wordt met zo'n wijziging bovendien geen praktisch probleem opgelost. Het erratum kan daarom afgesloten worden zonder het door te voeren.
Bij het genereren van schema's vanuit het UGM hoeft niet langer met restrictions in de schema's gewerkt te worden (zolang het op berichtniveau maar wel een restriction blijft). Het probleem met de overbodige choices wordt in de nieuwe koppelvlakken dus vanzelf opgelost.
Tijdens de StUF Expertgroep van 15 februari 2017 is dit Erratum afgevoerd.