Choice in choice constructies

6 reacties / 0 nieuw
Robert Melskens
Choice in choice constructies

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.

Robert Melskens

Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR287.
De lijst met onderhoudsverzoeken vind je op: 
www.gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Robert Melskens

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.

Robert Melskens

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.

  1. Het komt binnen het schema 'bg0310_msg_bag.xsd' voor binnen de 'element' elementen die de volgende berichten definiëren:

    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.

  2. Ook binnen het schema 'zkn0310_ent_basis.xsd' komen choice in choice constructies voor die wat vreemd ogen.

    • Binnen de complexType 'BTR-basis' is het aantal keren dat de choice herhaalt mag worden gelijk aan het aantal elementen dat in de choice voorkomt. Ook in de restrictions daarop ('BTR-kerngegevens', 'BTR-subtypeMDWOEH-basis' en 'BTR-subtypeMDWOEH-kerngegevens'). Dit doet mij vermoeden dat het requirement hier anders is dan het gebruik van de choice doet vermoeden.
      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.
    • Binnen de compelxType 'OBJ-basis' is het aantal keren dat de choice herhaalt mag worden eveneens gelijk aan het aantal elementen dat er in voorkomt. Ook hier doet dit mij vermoeden dat het requirement anders is dan het gebruik van de choice doet vermoeden. Alleen afgaand op OBJ-basis lijkt mij dat je er in deze situatie beter voor kunnen kiezen de choice te vervangen door een verplichte sequence en de elementen optioneel te maken. Dat ligt echter aan wat men met de gewenste constructie wil kunnen.
      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.
  3. 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.

 

Maarten van den...

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.

Robert Melskens

Tijdens de StUF Expertgroep van 15 februari 2017 is dit Erratum afgevoerd.