Vervang gebruik 'fixed' waarde voor entiteitType attribute voor enumeration

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

10 reacties / 0 nieuw
Login of registreer om te kunnen reageren
wo, 2-09-2015 - 11.16u
#1
Robert Melskens
Vervang gebruik 'fixed' waarde voor entiteitType attribute voor enumeration

Probleem
In de schema's van StUF-BG 3.10 maar ook in die van StUF-ZKN 3.10, StUF-ZTC 3.10 en mogelijk ook diverse koppelvlakschema's wordt veelvuldig gebruik gemaakt van het 'fixed' attribute voor het vastleggen van de waarde van de 'entiteitType', en 'groepsnaam' attributes in de StUF berichten. Zie onderstaand voorbeeld:

    <complexType name="BST-kerngegevens">
        <complexContent>
            <restriction base="ztc:BST-basis">
                <sequence>
                    <element name="omschrijving" type="ztc:Omschrijving-e" nillable="true" minOccurs="0"/>
                    <element name="omschrijvingGeneriek" type="ztc:Omschrijving-e" nillable="true" minOccurs="0"/>
                    <element name="maaktDeelUitVan" type="ztc:BSTCAT-kerngegevens" nillable="true" minOccurs="0"/>
                </sequence>
                <attribute ref="StUF:entiteittype" use="required" fixed="BST"/>
                <attribute ref="StUF:sleutelVerzendend"/>
                <attribute ref="StUF:sleutelOntvangend"/>
                <attribute ref="StUF:sleutelGegevensbeheer"/>
                <attribute ref="StUF:noValue" use="prohibited"/>
                <attribute ref="StUF:scope" use="prohibited"/>
                <attribute ref="StUF:verwerkingssoort"/>
            </restriction>
        </complexContent>
    </complexType>

Het blijkt dat het gebruik van dit attribute in sommige omgevingen bij code generatie problemen oplevert.

Oplossing
Ik stel een soortgelijke constructie voor als die we eerder i.h.k.v. ERR267 op de elementen 'functie' en 'entiteittype' hebben doorgevoerd, vervang daar waar een constructie als

                <attribute ref="StUF:entiteittype" use="required" fixed="BST"/>

voorkomt door een soortgelijke constructie als

                <attribute name="entiteittype" type="StUF:EntiteittypeBST"/>

Het type attribute verwijst daarbij naar een simpleType waarin slechts 1 enumeration is gedefinieerd, in dit geval dus

            <enumeration value="BST"/>

Voor de 3-letterige mnemonics kan daarbij gebruik gemaakt worden van de al aanwezige simpleTypes die voor het 'entiteittype' element in de stuurgegevens worden gebruikt. Voor de meerletterige mnemonics en andere waarden zullen nieuwe simpleTypes aangemaakt moeten worden.

Bovenaan
Robert Melskens

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

Bovenaan
Robert Melskens

Ik heb een analyse uitgevoerd op dit probleem, de wijze waarop het opgelost moet worden en de implicaties. Zie daarvoor bijgaand spreadsheet.

  • In de eerste tab ('beoogde transformatie') geef ik aan hoe het probleem opgelost kan worden. In kolom B de bestaande situatie en in kolom C de te creëren situatie;
  • Tab 2 ('Sorted op bestandsnaam') geeft het resultaat van een query die ik heb gedraaid op de schema's van de StUF onderlaag en de 3 sectormodellen. Daarin staan van alle 'xs:attribute' elementen in die schema's waar een 'fixed' attribute op voorkomt resp. de waarde van het 'ref' attribute, de waarde van het 'name' attribute, de waarde van het 'fixed' attribute en de naam van het schema waarin het xs:attribute staat;
  • Tab 3 ('Sorted op fixed waarde') is gelijk aan tab 2 alleen is deze nu gesorteerd op 'fixed' attribute waarde;
  • Tab 4 ('Unieke fixed waardes') geeft alle gevonden unieke 'fixed' attribute waarden;
  • Tab 5 ('simpleTypes met relev waarden') geeft een overzicht van alle, op basis van de waarden in tab 4, gevonden simpleTypes (wederom in alle schema's van de StUF onderlaag en de 3 sectormodellen) waarin slechts 1 'xs:enumeration' element staat (en die dus geschikt zijn om te gebruiken als vervanging voor het 'fixed' attribute. In dit overzicht staat de waarde van het 'value' attribute van het 'xs:enumeration' element, de naam van het simpleType waarin deze voorkomt en de naam van het schema waarin het simpleType staat.
  • In tab 6 ('te transformeren') staan tenslotte de daadwerkelijk uit te voeren transformaties. Voor de rijen waarin de kolommen E en F gevuld zijn geldt situatie nr 1 of 3 uit de eerste tab.
    Voor de rijen waarin kolom E en F leeg zijn geldt situatie nr 2 of 4 uit de eerste tab. Daar dient nog een nieuw simpleType gecreëerd te worden. Daar waar een waarde gebruikt moet kunnen worden in zowel de StUF-BG als de StUF-ZKN namespace definiëren we een simpleType in de StUF-BG namespace. Daar waar een waarde in slechts 1 namespace gebruikt hoeft te worden definiëren we een simpleType in die betreffende namespace.
    Daar waar een waarde gebruikt moet kunnen worden in zowel de StUF-ZKN als de StUF-ZTC namespace definiëren we een simpleType in beide namespaces.

Zoals je kunt zien moeten er voor het oplossen van dit issue op 1338 plaatsen xs:attributes te worden gewijzigd. Deels zal dat met zoeken en vervangen kunnen maar deels zal het ook handmatig moeten gebeuren. Daarom de vraag om even goed te kijken of jullie je kunnen vinden in de voorgestelde oplossing.

Bijlage

xs-attributes met fixed attribute.xlsx
Bovenaan
Henri Korver

Interessant onderhoudsverzoek! Het is nog even de vraag of we dit verzoek moeten doorvoeren als erratum op stuf0310, bg0310, zkn0310, ztc0310 en mogelijk op bestaande koppelvlakken. Dat is veel werk en vooral een foutgevoelige operatie met kans op onverwachte neveneffecten.

Dit onderhoudsverzoek is wel zeer geschikt als RFC op stuf0302 en de best practices. In de nieuwe standaarden bg0320, zkn0320, koppelvlakken (etc.) is het mijns inziens sowieso gewenst geen fixed-values meer te gebruiken.

Bovenaan
Henri Korver

Inmiddels heb ik dit onderhoudsverzoek op bg0310 gegeneraliseerd naar een RFC op stuf0301 en de best practices, zie https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/stuf-301/rfc-vervang-...

 

 

 

Bovenaan
Robert Melskens

De best practice is aangepast, zie bijgaand voorstel.

Bijlage

stuf_best_practices - ONV0401.pdf
Bovenaan
Robert Melskens

Tijdens de StUF Expertgroep van 18 mei 2016 is het voorstel goedgekeurd. De schema's hoeven nav het voorstel niet aangepast te worden.

Bovenaan
Robert Melskens

N.a.v. het afkeuren van RFC0416 is besloten om de wijzigingen n.a.v. ERR0401 ook terug te draaien.
Hiervoor heb ik ERR0476 in de onderhoudsverzoeken opgevoerd.
De lijst met onderhoudsverzoeken vind je op: 
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Bovenaan
Robert Melskens

Bij deze de uitwerking van de gevraagde wijziging.

Bijlage

stuf_best_practices - ERR0476 (met renvooi).pdf
Bovenaan
Robert Melskens

Tijdens de StUF Expertgroep van 15 maart 2017 is de uitwerking van dit onderhoudsverzoek goedgekeurd en is tevens goedgekeurd deze al meteen op te nemen in patch 26.

Bovenaan