Ik probeer de schema's te gebruiken om Java code te genereren, maar stuit op een probleem waarbij ik zie dat de schema's vreemd gebruikt worden.
In mijn voorbeeld probeer ik een NPSLv01 bericht te creëren in Java.
Zowel de NPS-vraagSelectie als de NPS-vraagScope hebben restriction base BG:NPSNINING-basis.
Als eerste element in de vraag elementen staat het volgende:
<choice minOccurs="0" maxOccurs="2">
<sequence minOccurs="0">
<element name="inp.bsn" type="BG:BSN-e" nillable="true" minOccurs="0"/>
<element name="authentiek" type="BG:Authentiek" default="N" nillable="true" minOccurs="0"/>
</sequence>
<element name="anp.identificatie" type="BG:IdentificatieRPSBTL-e" nillable="true" minOccurs="0"/>
</choice>
XSD technisch betekent dit volgens mij dat je het volgende kan sturen:
<inp.bsn nil=true>
<authentiek nil=true>
<inp.bsn nil=true>
<authentiek nil=true>
of
<anp.identificatie=true>
<anp.identificatie=true>
of
<anp.identificatie=true>
<inp.bsn nil=true>
<authentiek nil=true>
of
<inp.bsn nil=true>
<authentiek nil=true>
<anp.identificatie=true>
of 1 van de twee choices of zelfs helemaal niets.
Dit is natuurlijk voor zowel de vraagselectie als vraagscope niet juist.
Voor de vraagSelectie zou het het volgende moeten zijn:
<choice minOccurs="0">
<sequence minOccurs="0">
<element name="inp.bsn" type="BG:BSN-e" nillable="true" minOccurs="0"/>
<element name="authentiek" type="BG:Authentiek" default="N" nillable="true" minOccurs="0"/>
</sequence>
<element name="anp.identificatie" type="BG:IdentificatieRPSBTL-e" nillable="true" minOccurs="0"/>
</choice>
en de vraagScope:
<element name="inp.bsn" type="BG:BSN-e" nillable="true" minOccurs="0"/>
<element name="authentiek" type="BG:Authentiek" default="N" nillable="true" minOccurs="0"/>
<element name="anp.identificatie" type="BG:IdentificatieRPSBTL-e" nillable="true" minOccurs="0"/>
Ik begrijp dat dit is gedaan om maar 1 BG:NPSNINING-basis te moeten definiëren, maar validatie technisch klopt het volgens mij niet.
Deze situatie komt vrij vaak voor
Zo zie ik ook in dezelfde BG:NPSNINING-basis en alle afgeleiden het volgende staan:
<choice minOccurs="0" maxOccurs="2">
<element name="verblijfsadres" type="BG:VerblijfsadresGrp-vraag" minOccurs="0"/>
<element name="sub.verblijfBuitenland" type="BG:VerblijfBuitenlandGrp" minOccurs="0"/>
</choice>
Wat is hier precies de bedoeling van?
De reden dat ik dit ook vraag is omdat de WSDL naar Java conversie niet goed overweg kan met choices die meer dan 1 keer kunnen voorkomen. Zodra hier een maxOccurs in staat, wordt hier in Java een List<Object> gegenereerd waarbij Object voor 1 Choice staat ipv een apart JaxbElement<object> binnen de te maken choices. Ik mag in de List<Object> alleen gegenereerde objecten in stoppen, maar daar kan ik voor het vraagScope deel van het bericht geen nil=true aan het element toevoegen.
Ik heb al eens gekeken naar de XSD Resolver, maar aangezien ik met meerdere sectormodellen tegelijk moet werken en ik de nieuwe XSD's niet meer in een WSDL krijg (door conflicten met de import van stuf0301_types.wsdl) is dit voor mij geen oplossing.
Mvg,
Lex
Lex,
Aangezien de XSD Resolver de samenstelling en naamgeving van de schema's wijzigt moeten de bijbehorende WSDL's natuurlijk ook aangepast worden. Ik neem aan dat je de volgende bewerkingen hebt uitgevoerd:
De resolver zal de choice constructie overigens niet aanpassen.
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0364.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Robert,
bedankt voor je reactie.
Ik zal dit nog eens proberen voor alleen sectormodel StUF BG 3.10.
Als ik dit zo werkend krijg heb ik nog één puntje en dat is dat ik code moet genereren voor diverse sectormodellen zoals :
- StUF BG 3.10,
- StUF ZKN 3.10,
- StUF EF 3.12 / 3.15
- StUF WOZ 3.12
Als ik deze per sectormodel door de XSD resolver haal en op basis van die schema's code genereer dan heb ik een overlap in code wat de generator (nog) niet wil accepteren.
Ik zal eerst nog een poging wagen om een goed gevalideerde WSDL te maken m.b.v. de aangepaste schema's, dan kijk ik later wel weer naar het generatie process.
Wat betreft het niet aanpassen van de choice constructie, dat mij onlangs ook opgevallen.
Robert,
Ik ben niet bevoegd om het overzicht met onderhoudsverzoeken te bekijken.
Wanneer ik een poging doe om in te loggen met de zelfde gegevens als wat ik hier gebruik, krijg ik de melding dat de gebruiker niet bestaat.
Wanneer ik via link wachtwoord vergeten klik op 'Maak een nieuwe gebruiker aan' (http://www.wikixl.nl/wiki/basisgemeente/index.php/Speciaal:Aanmelden/signup) dan moet ik eerst aangemeld zijn.
Is het toegestaan dat ik daar in mag kijken en zo ja hoe kom ik aan een gebruikersaccount waarmee ik dit kan bekijken?
Mvg,
Lex
Lex,
Probeer het nog maar eens, ik had per abuis de verkeerde link geplaatst. In het bestand dat nu in GEMMA Online staat staat dit issue overigens nog niet opgevoerd. Als het goed is is dat morgenochtend wel het geval.
Top het werkt.
Dank je wel Robert.
De instructie die ik in een van mijn bovenstaande reacties geef is blijkbaar niet helemaal compleet. Om die reden hieronder nomaals met de correcties (in vet):
Tijdens de StUF Expertgroep van 18 februari 2015 is aangegeven dat men hier tegenaan liep bij het genereren van code. We zouden de schema’s strakker kunnen krijgen door geen restricties meer te hanteren. Dat is onderhouds-technisch echter niet gewenst. Maarten van den Broek adviseert om hiervoor de XSD Resolver te gebruiken.
De Expertgroep heeft geconstateerd dat dit geen fundamenteel probleem is maar een best-practice probleem (hoe zet je een schema in elkaar). Het onderhoudsverzoek blijft nog openstaan.
Het wijzigen van bestaande schema's voor StUF0301 is niet wenselijk.
Bij het genereren van de schema's voor nieuwe koppelvlakken op basis van het UGM zal dit probleem worden opgelost.
Het onderhoudsverzoek kan worden afgesloten.
Tijdens de StUF Expertgroep van 15 februari 2017 is dit onderhoudsverzoek afgevoerd.