Ik ben bezig mij in te lezen in StUF 0301 en StUF BG 3.10 en heb een paar vragen.
In het document stuf0301.pdf uit het zip bestand Bg0310_20150630_patch22.zip, staat op pagina 99 een voorbeeld van een vraagbericht over een natuurlijk persoon:
<rpsLv01 xmlns:StUF=”http://www.egem.nl/StUF/StUF0301” xmlns=”http://www.egem.nl/StUF/sector/bg/0310”>
<stuurgegevens>
<StUF:berichtcode>Lv01</StUF:berichtcode>
<StUF:entiteittype>RPS</StUF:entiteittype>
</stuurgegevens>
<parameters>
<StUF:sortering>1</StUF:sortering>
</parameters>
<gelijk StUF:entiteittype=”RPS”>
<postcode>5115XN</postcode>
<huisnummer>19</huisnummer>
</gelijk>
<scope>
<natuurlijkPersoon StUF:entiteittype=”NPS”>
<bsn xsi:nil=”true”/>
<naamsgegevensGrp>
<geslachtsnaam xsi:nil=”true”/>
<voorletters xsi:nil=”true”/>
</naamsgegevensGrp>
<verblijftIn StUF:entiteittype=”NPSTGO”>
<gerelateerde StUF:entiteittype=”TGO”>
<adresAanduidingGrp>
<woonplaats xsi:nil=”true”/>
<postcode xsi:nil=”true”/>
<huisnummer xsi:nil=”true”/>
<huisletter xsi:nil=”true”/>
<huisnummertoevoeging xsi:nil=”true”/>
</adresAanduidingGrp>
</gerelateerde>
</verblijftIn>
</natuurlijkPersoon>
<nietNatuurlijkPersoon StUF:entiteittype=”NNP”>
<fiNummer xsi:nil=”true”/>
<statutaireNaam xsi:nil=”true”/>
<correspondentieAdresAanduidingGrp>
<woonplaats xsi:nil=”true”/>
<postcode xsi:nil=”true”/>
<huisnummer xsi:nil=”true”/>
<huisletter xsi:nil=”true”/>
<huisnummertoevoeging xsi:nil=”true”/>
</correspondentieAdresAanduidingGrp>
</nietNatuurlijkPersoon>
</scope>
</rpsLv01>
1. In het bovenstaande bericht, staan geslachtsnaam en voorletters in de naamgegevensGrp, echter als ik in het xsd bestand bg0310_ent_basis.xsd kijk naar de elementen die bij een natuurlijk persoon horen (loopt terug tot het element NPSNINING-basis, staan geslachtsnaam en voorletters niet in een bepaalde groep, maar hangen direct onder het element van NPSNINING-basis, mijn vraag hierover is dan ook. waarom staan deze twee elementen in het voorbeeld bericht in een groep?
2. In het voorbeeld bericht begint de scope van een natuurlijk persoon met <natuurlijkPersoon StUF:entiteittype="NPS">, als ik in het xsd document bg0310_msg_vraagAntwoord.xsd kijk dan staat daar dat in de scope een element met de naam object, dus ik zou dan verwachten dat het eerste element van de scope in het vraagbericht <object StUF:entiteittype="NPS"> zou zijn, kan ik hieruit opmaken dat de naam van het object niet uitmaakt, zolang het entiteittype er maar in staat vermeld?
3. voor een aantal van de elementen onder het complextype NPSNINING-basis beginnen een aantal element met "sub.", "inp." of "sub.". Dit staat bijvoorbeeld bij het bsn van een natuurlijk persoon <element name="inp.bsn" type="BG:BSN-e" nillable="true" minOccurs="0"/>, als ik dit element wil opnemen in de scope, moet ik dan ook het "inp." gedeelte overnemen, of kan ik alleen "bsn" gebruiken, als het laatste het geval is, waarom staan deze afkortingen dan in de naam van het element?
Met vriendelijke groet,
Freek van der Toorn
Dag Freek,
Goed dat je er zo grondig doorheen gaat, daarmee komen altijd weer kleine foutjes in de standaard aan het licht. Bij deze de antwoorden op je vragen:
Overigens moet je je bij het vullen van het 'object' natuurlijk wel aan het schema houden. In dit bericht mag het 'object' element op deze locatie alleen de elementen 'natuurlijkPersoon' en 'nietNatuurlijkPersoon' bevatten.
Het betreft elementen die oorspronkelijk afkomstig zijn uit andere entiteiten. Zo is het element 'inp.bsn' bijvoorbeeld afkomstig uit de entiteit 'INP' (Ingeschreven Persoon). De beschrijving daarvan kun je terugvinden in het informatiemodel behorende bij StUF-BG 3.10 (RSGB 2.01). Bij het omzetten van het informatiemodel naar XML-Schema's (wij noemen dat de verStUFfing) heeft de ontwerper er voor gekozen om de relatie tussen de entiteit 'RPS' en de entiteit 'INP' plat te slaan in het object voor de entiteit 'RPS'. Een beslissing die hij waarschijnlijk genomen heeft omdat dit technische voordelen gaf. Om de oorspronkelijke relatie met 'INP' niet te verliezen voegen we in deze gevallen de mnemonic van de oorspronkelijke entiteit (INP) in kleine letters aan de naam van het element toe gescheiden door een '.' met als resultaat dus 'inp.bsn'.
Nog een tip, hou bij je zoektocht door de standaard goed de schema's in de gaten want die zijn normatief niet de voorbeelden in de standaard.
In de onderhoudsverzoeken is het onderhoudsverzoek ONV0399 opgevoerd n.a.v. de foutjes in het StUF fragment op pagina 99 van de StUF standaard. De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Beste Robert,
Bedankt voor je reactie, ik zit echter nog wel met wat vragen. Ik gebruik XML-spy om mijn berichten te valideren tegenover 'bg0310_msg_stuf_vraagAntwoord.xsd' en hier heb ik nog wel wat problemen mee. Volgens het schema mag onder het <object> geen natuurlijkPersoon of nietNatuurlijkPersoon bevatten. Ik vermoed zelf dat ik het verkeerde schema gebruik om mijn xml berichten mee te vallideren. Kan jij mij vertellen welk schema ik moet gebruiken hiervoor?
Hoi Freek,
VraagAntwoord berichten moet je valideren tegen 'bg0310_msg_vraagAntwoord.xsd' of tegen het 'bg0310_msg_totaal,xsd' schema dat 1 niveau hoger staat.
In deze discussie wordt alleen gewezen op foutjes die zouden staan in het fragment op pagina 99. Bij het verwerken van het gerelateerde onderhoudsverzoek (ONV0399) bleek echter dat het StUF fragment op pagina 99 niet het enigste foutieve fragment is. Omdat het weinig zin heeft het ene fragment wel te wijzigen en het andere niet zijn enkele andere fragmenten ook gecorrigeerd. In de bijgeleverde gerenvooieerde versie van de StUF standaard (zie bijgaande zip) dus op pagina 99, 103, 106, 109, 112, 114, 115, 116, 122, 123 en 126. Ook in de teksten rondom de fragmenten zijn hier en daar wijzigingen aangebracht.
In het document Verantwoording wijzigingen n.a.v. ONV0399.pdf (zie eveneens de bijgaande zip) heb ik de wijzigingen becommentarieerd en hier en daar doe ik nog voorstellen tot het verbeteren van de tekst.
Tenslotte heb ik geconstateerd dat er ook in de fragmenten in andere delen van de StUF standaard fouten staan.
Deze heb ik voor nu onaangeroerd gelaten aangezien ik eerst de discussie over deze wijzigingen wil afwachten.
Bijlage
Voor het gemak ook even alle gecorrigeerde fragmenten in afzonderlijke XML bestanden. Hier en daar zijn de fragmenten aangevuld om valide berichten te verkrijgen.
Bijlage
Tijdens de StUF Expertgroep van 21-10-2015 zijn we helaas niet aan de behandeling van het bovenstaande voorstel toegekomen. Er is daarom toen afgesproken dat de aanwezige leden eventuele bezwaren binnen 2 weken na de betreffende bijeenkomst kenbaar zouden maken. Aangezien geen bezwaren zijn geplaatst is het voorstel aangenomen en het zal dan ook meegenomen worden in pre-patch 23.
Tijdens de StUf Expertgroep van 18 november 2015 is besloten de voorgestelde oplossing op te nemen in patch 23.