Vanuit de WOZ-inzage (mijnOverheid) kant de volgende vraag:
Voor het terugleveren van een Taxatieverslag voor de WOZ-inzage is het bericht 'mijnOverheid-antwTaxatieverslag' gedefinieerd. Daarin zie je een attribuut pdfTaxatieVerslag, waarbij het taxatieverslag als mtom aangeleverd dient te worden. Hiervoor dient volgens Logius een child element xop:Include aan pdfTaxatieVerslag toegevoegd te worden met de verwijzing naar het gekoppelde document (zie www.logius.nl/fileadmin/logius/ns/diensten/mijnoverheid/koppelvlakspecif..., paragraaf 4.4.6, pagina 27), maar dit is volgens het XSD niet geldig (StUF:BinaireInhoud-basis staat dit niet toe).
Dit is op te lossen door in BinaireInhoud-basis een optioneel attribuut any op te nemen.
Momenteel wordt deze werkwijze al gebruikt en er wordt dus niet meer gevalideerd tegen de stuf-xsd's. Iedere referentie die ik tot nu toe naar dit gebruik van xop binnen StUF zie ik dat de xsd-validatie wordt uitgezet voor deze koppelingen.
Dit probleem lijkt zich ook voor te doen bij StUF-ZKN waarbij deze werkwijze blijkbaar ook wordt gebruikt.
In de .net wereld zie je ook al vaak 'xop implementaties' zonder noodzakelijk gebruik van MTOM, bijv bij StUF bevragingen.
Is het noodzakelijk om hierop ook beleid te ontwikkelen in het kader van StUF protocol bindingen?
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0477.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Ik ben bang dat Logius de validatie van berichten, waarbij MTOM wordt gebruikt niet correct geïmplementeerd heeft. De MTOM specificatie schrijft voor dat het meegestuurde binary bestand in base64 encoding geacht wordt te zitten in het element pdfTaxatieverslag. Op de lijn, tijdens de afhandeling in de SOAP-stack en mogelijk ook bij opslag van het bericht in berichtenbuffers zal de bijlage niet in base64 formaat binnen de xml worden opgenomen. In dat geval zal de xml niet valideren en dat is in wezen ook wat je wilt, want de xml voldoet niet aan het schema.
De correcte oplossing is om voor de validatie eerst te checken of er xop:Include elementen zijn en zo ja om die te vullen met de base64 encoding van het binary bestand en vervolgens te valideren.
Een mogelijke workaround is om in het schema waartegen gevalideerd wordt het complexType BinaireInhoud-e te vervangen door een type met mixed content met erbinnen het xop:Include element. Het is niet wenselijk om dit in de StUF-standaard zelf te doen, omdat een dergelijk schema het bericht niet correct specificeert.
Tijdens de StUF Expertgroep van 15 maart 2017 is besloten dit onderhoudsverzoek af te wijzen. Het oplossen van het probleem wordt niet gezien als iets wat binnen de StUF Schema's moet gebeuren. Maarten v.d. Broek ziet dit als een probleem dat Logius moet oplossen.