In StUF 0301 is op bladzijde 92 beschreven hoe de scope moet worden gedefinieerd:
Ten behoeve van de zesde mogelijkheid worden de gevraagde gegevens gespecificeerd binnen het element <object> in het element <scope>. Voor een fundamenteel entiteittype bevat het element <object> in het element <scope> een element met een willekeurige naam en met als attribute StUF:entiteittype het fundamentele entiteittype. Dit element bevat dan als elementen de gevraagde gegevens en relaties conform het contentmodel voor het antwoordbericht.
Een gegeven wordt gevraagd door het op te nemen als een element met een lege inhoud en het attribute xsi:nil=”true”.
Dit wijkt af van hoe het in Bg0204 gedefinieerd was. Daarin werd ook een attríbuut 'noValue' opgenomen.
Nu blijkt dat binnen bg0310 vragen dit attribuut ook nog wordt toegepast door leveranciers.
Daarbij wordt aangegeven dat de Bg0310 XSD voor vraag/antwoord wordt het gebruik van attribuut 'noValue' niet uitsluit. Ook wordt aangegeven dat het StUF testplatform het gebruik toestaat.
Andere leveranciers hebben de beschrijving van StUF 0301 gevolgd en staan het gebruik van dit attribuut niet toe in de afhandeling van de vragen.
De vraag aan KING: Wat is bindend?
de StUF 0301 beschrijving of de xsd en testplatform?
Ik ben het niet helemaal eens met de zin "Andere leveranciers hebben de beschrijving van StUF 0301 gevolgd en staan het gebruik van dit attribuut niet toe in de afhandeling van de vragen."
In het document wordt niet geproken over het attribuut noValue (in deze context). Daarmee is het mijns inziens niet expliciet verboden. Je kunt je dus afvragen of het niet toestaan van het attribuut geheel conform de beschrijving is.
Blijft de vraag wat nu de regel in dit geval is: is het attribuut toegestaan of niet. In het eerste geval moeten xsd's en in ieder geval STP worden aangepast. In het andere geval zou ik graag expliciet in de documentatie zien staan dat gebruik van het attribuut verboden is in deze context.
De StUF-standaard is op dit punt niet dubbelzinnig. Het is niet in de schema's afgedwongen, omdat je dan van elk "-e" complexType weer een restriction moet maken en ook een extra type voor de scope moet maken dat die resticted complexTypes gebruiken en het sop leek hier de kool niet waard.
Het is natuurlijk wel heel vervelend dat het StUFtestplatform dit niet afdwingt. Ik zelf zou kunnen leven met de oplossing dat beide vormen zijn toegestaan in StUF0301, omdat er al implementaties zijn. Het lijkt mij namelijk niet buitengewoon ingewikkeld voor partijen om een vraagbericht correct te verwerken ongeacht het al dan niet aanwezig zijn van het noValue attribute.
In StUF0302 zal een en ander wel strak geïmplementeerd moeten worden.
N.m.m. moet in de betreffende paragraaf van de standaard (stuf0301.xsd) worden aangegeven dat beide opties zijn toegestaan. Op basis daarvan kan dan het StUF Testplatform worden aangepast.
Dit erratum is opgevoerd in de onderhoudsverzoeken als ONV0411.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Het blijkt overigens dat ook het StUF Testplatform in het prefill eFormulieren koppelvlak een variant hanteert die niet is toegestaan door de StUF-standaard, namelijk het opnemen van een element zonder xsi:nil="true". Het lijkt me verstandig in het kader van de interoperabiliteit om dit dan ook maar toe te staan.
De beschrijving lijkt mij duidelijk genoeg. "Een gegeven wordt gevraagd door het op te nemen als een element met een lege inhoud en het attribute xsi:nil=”true”.
Ik lees hier niet uit af dat daarmee ook andere attributen zijn toegestaan.
Ik vind het daarom ook geen erratum waarbij beide opties moeten worden ondersteund.
In StUf 0204 staat de noValue nog vernoemd als attribuut op te nemen bij de scope.
In de mapping van StUF 0204 naar StUF 0301 staat expliciet aangegeven dat dit in StUF 0301 anders is.
"8.3 Mapping selectie, scope en start van StUF0204 naar StUF0301
Als het eerste en tweede element in het StUF0204 vraagbericht gelijk zijn, dan wordt het eerste element gemapt op <gelijk> in het StUF0301-vraagbericht conform de regels in hoofdstuk 3. Als het eerste en tweede element verschillen, dan wordt het eerste element gemapt op <vanaf> element en het tweede element op <totEnMet>.
Het derde element in het StUF0204 vraagbericht wordt gemapt op <scope>. Hierbij geldt als extra regel, dat het attribute StUF:noValue=”geenWaarde” niet wordt overgenomen in <scope>."
Gezien het bovenstaande lijkt me de enige goede uitleg te zijn dat in de scope het attribuut noValue niet mag voorkomen.
Inmiddels is dan nu wel duidelijk wat oorspronkelijk de bedoeling was.
Gezien de historie (in 02.04 was het attribut zelfs verplicht) en het feit dat het niet expliciet is verboden in de 3.10-versie (behalve in het mapping-document), zou het wellicht toch een goed idee kunnen zijn om vooralsnog berichten mét het attribuut niet te verbieden. Het STP accepteert ze per slot van rekening ook nog.
Wellicht een agendapuntje voor het volgende overleg van de expertgroep?
Ik wil vasthouden aan de bedoeling in 0301. Deze is niet zomaar random er in gekomen.
Deze is al bij meerdere leveranciers doorgevoerd en operationeel. Het issue dat ik hier heb gemeld is ontstaan omdat er leveranciers zijn die de defintie van de scope anders hebben geinterpreteerd waardoor gemeenten nu geconfronteerd worden met uitval.
Het lijkt me een normale zaak dat niet de leveranciers die de definitie volgen, hun software moeten aanpassen.
De StUF-berichtenstandaard is natuurlijk de norm boven de schema’s (van sectormodellen / koppelvlakken) en het STP. De StUF 3.01 standaard stelt dat in de scope van een vraagbericht de gevraagde gegevens opgenomen dienen te worden met lege inhoud en het attribute xsi:nil=”true”. Het is dus niet de bedoeling het attribute StUF:noValue ook op te nemen, want anders was dat wel expliciet gemeld. Applicaties (inclusief de STP) die hier niet aan voldoen zullen moeten worden aangepast.
In StUF 3.02 zullen we dit scherper (op schemaniveau) specificeren.
Tijdens de StUF Expertgroep van 20 januari 2016 is besloten dit onderhoudsverzoek af te voeren.