We krijgen van het testplatform een fout terug op ons 1.0 VTO (zie bijlage)
In het VTO is het volgende element opgenomen: <ns3:heeftBetrekkingOpAndere xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
Omdat dit element geen waarde bevat is het (in ieder geval voor Java) lastig om een entiteittype mee te geven. Hier is wat kunst en vliegwerk voor nodig wat mogelijk een grote impact op de rest van de code heeft. Is het mogelijk dat de verplichtheid van het meesturen van een entiteittype er uit wordt gehaald als een element geen waarde bevat?
Hetzelfde geldt voor het volgende element in de zaakmelding terugkoppeling
<ZKN:heeftAlsInitiator ZKN:entiteittype="ZAKBTRINI" ZKN:noValue="geenWaarde">
<ZKN:heeftAlsAanspreekpunt xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
</ZKN:heeftAlsInitiator>
Volgens de ad hoc tester moet heeftAlsAanspreekpunt een entitieittype hebben
Erwin,
Ik begrijp je punt en ik ga dit dan ook even bespreken. In de StUF standaard staat op pagina 24 echter:
Het attribute StUF:entiteittype geeft aan wat het entiteittype is van het object.
Dit attribute is verplicht op elk element voor een entiteittype uit het sectormodel.
Het kan dus zijn dat dit pas wordt gecorrigeerd in een versie van de CORV schema's die gebaseerd zijn op een nieuwe versie van de StUF standaard.
We stellen voor de relatie 'heeftBetrekkingOpAndere' net als in het notificatiebericht (zie deze discussie) optioneel te maken.
Daarmee wordt het probleem dat Erwin hier schetst opgelost.
In je eigen reactie op deze discussie geef je aan dat je ook een probleem hebt met het relatie-element 'heeftAlsInitiator'. Het was me niet eerder opgevallen maar op dat element heb je het attribute 'ZKN:noValue' gedefinieerd. Zo´n element bestaat echter helemaal niet, het moet 'StUF:noValue' zijn. Wellicht lost het corrigeren van deze fout je probleem al op omdat het element 'heeftAlsAanspreekpunt' niet meer aan 'heeftAlsInitiator' hoeft te worden toegekend. Of het eveneens optioneel maken van 'heeftAlsInitiator' in een zorgmeldingTerugkoppeling, om het probleem fundamenteel op te lossen, mogelijk is moet nog bekeken worden.
Erwin,
Ik heb inmiddels informatie gekregen waaruit blijkt dat we 'heeftBetrekkingOpAndere' niet optioneel kunnen en hoeven te maken. Bij een VTO-zaak heeft de BetrekkingOpAndere-zaak betrekking op de door de RvdK te starten onderzoekszaak. De BetrekkinOpAndere-zaak is, vanuit de gemeente gezien, het verzoek om een onderzoekszaak te starten. Deze is er dus altijd, in een VTO-bericht. En deze heeft ook altijd elementen: minimaal de Zaaktype-omschrijving (van de te starten onderzoekszaak) en de extraElements Datum indiening en Jeugdzorgrol verzoeker. De door jou geschetste situatie waarbij 'heeftBetrekkingOpAndere' leeg is mag dus helemaal niet voorkomen.
Voor 'heeftAlsInitiator' geldt zo'n beetje hetzelfde, ook die kunnen we niet optioneel maken.
In de koppelvlakbeschrijving staat over 'heeftAlsInitiator' nl. het volgende:
De initiator kan dus niet optioneel zijn: het is degene die de zorgmelding ingediend heeft. Die is ontvangen in de Zorgmelding(-bericht) en wordt daaraan ontleend. Evenzo is er altijd een heeftAlsAanspreekpunt: de medewerker namens de initiator die de zorgmelding heeft ingediend. Ook deze wordt aan de Zorgmelding(-bericht) ontleend.
We vragen onszelf trouwens af of je geen problemen hebt met xsi:nil=”true” in combinatie met StUF:noVlaue i.p.v. StUF:entiteittype?
Dag Robert,
Dank voor je antwoord. Graag zouden wij willen weten waar we die informatie kunnen vinden. Uit de koppelvlak beschrijving en de XSDs kunnen we namelijk niet opmaken dat deze elementen verplicht moeten zijn. Zie ook de bijgevoegde schermprints.
We sturen in de huidige implementatie (094) geen heeftBetrekkingOpAndere - zaak mee, immers, de VTO initieert het onderzoek en de afzender is onze CORV applicatie, geen zaaksysteem. Dit veld is dan ook niet verplicht in de xsd (zie screenshot 'vto'. Bijgevoegd ook het screenshot 'heeftBetrekkingOpAndere p19', hieruit maken wij op dat dit om de zaak bij de RvdK gaat, deze kan het VTO versturende systeem toch niet kennen? Of dit moet een eerdere binnen gekomen Zorgmelding zijn, maar dit is lang niet altijd het geval.
Wij kunnen prima als heeftAlsInitiator een vulling mee geven als 'politie' o.i.d. ondanks dat dit veld ook volgens het XSD niet verplicht is (en blijkbaar van alles hierin mag staan?), echter als de medewerker gevuld moet worden in heeftAlsAanspreekpunt dan hebben we mogelijk een ander probleem: de medewerker is een niet verplicht element in de zorgmelding. Zie screenshots 'zorgmeldingTerugkoppeling' en 'zorgMelding'.
Wij zijn van mening dat de specificaties niet volledig zijn en het testplatform een semantiek af dwingt die niet door de standaard afgedwongen wordt. Het stuf testplatform zou zolang de specs niet overeenkomen met bovenstaande verhaal deze validaties moeten laten vallen.
Vriendelijke groet,
Erwin
Bijlage
Erwin,
Ik vraag me af waaruit jij de conclusie trekt dat de elementen 'heeftBetrekkingOpAndere' in het VTO bericht en 'heeftAlsInitiator' in het Zorgmelding en ZorgmeldingTerugkoppeling bericht niet verplicht zijn? Als je naar jou schermprints kijkt dan zie je dat deze elementen geen minOcurs="0" bevatten. Uit de schermprints die ik heb bijgevoegd kun je ook zien dat de inhoud ook verplichtte elementen bevat.
Wellicht dat het feit dat deze elementen het attribute nillable="true" bevatten deze indruk wekt. Dit is n.m.m. dan ook een bug die we moeten herstellen in een volgende versie.
Ik begrijp trouwens ook niet dat je zegt dat in een 'heeftAlsInitiator' van alles mag staan. Uit mijn schermprintjes blijkt dat dit
niet het geval is. Tevens blijkt uit mijn schermprints dat 'heeftAlsAanspreekpunt' (de medewerker) juist wel een verplicht veld is.
Je zegt trouwens dat de CORV applicatie geen zaaksysteem is. Dit is natuurlijk mogelijk maar je legt in de CORV applicatie wel zaken vast en wisselt informatie uit met andere systemen middels zaakberichten.
Bijlage