Het voegZaakdocumentToe berichttype in ZDS 1.2 specificeert een "object . inhoud" element. Het is mij echter onduidelijk wat het formaat is van de waarde die hierin kan staan.
ZDS 1.2 verwijst naar RGBZ-attribuut "Documentinhoud". In RGBZ 1.0 wordt vervolgens gesproken over "desbetreffend Documentformaat". (In RGBZ 2.0 wordt gesproken over MIME-content, wat verder nergens gedefinieerd is).
Zie: https://www.gemmaonline.nl/index.php/Rgbz_1.0/doc/objecttype/enkelvoudig...
Het StUF-testplatform gebruikt een dubbel encoded base64 string (was even puzzelen) dat is opgenomen in het XML bericht. Dit lijkt inderdaad goed te werken.
Het is dus aan de consumer om een dubbel encoded string op te nemen in de berichten?
In het document keuzenVerStUFfing RGBZ (https://www.gemmaonline.nl/images/gemmaonline/6/6c/KeuzenVerStUFfing_RGBZ.pdf) staat op pagina 7:
Het attribuutsoort documentInhoud is opgenomen in de StUF-entiteit EDC als het element met als elementnaam 'inhoud' met als complexType StUF:BinaireInhoud gedefinieerd in het schema stuf0301mtom.xsd. Het sectormodel zkn0310 maakt daardoor voor het verzenden van binaire bijlagen gebruik van de protocolbinding 0301.
In de StUF protocolbinding (https://www.gemmaonline.nl/images/gemmaonline/3/37/Stuf.bindingen.030204.pdf) staat in paragraaf 3.1 (p.6) uitgelegd hoe binaire bijlagen in StUF meegestuurd kunnen worden:
Binaire bijlagen kunnen in een XML-bericht worden opgenomen door middel van elementen van het type base64binary uit de namespace “http://www.w3.org/2001/XMLSchema” ..
Verdere details staan in de rest van paragraaf 3.1 uitgelegd. Om op je vraag terug te komen: document.inhoud is van het type StUF:binaireInhoud en bevat een base64 encoded string. Of die dubbel encoded is durf ik niet te zeggen, dat kan ik nl. nergens terugvinden.
NB. ik heb de discussie even naar het koppelvlak Zaak- Documentservices verplaatst, de gebruikte berichten zijn nl. uit dat koppelvlak afkomstig.
Ha Michiel,
Uit de XSD haalde ik hetzelfde, maar die geeft aan dat het veld base64 encoded is. Ik vroeg me af waarom het StUF testplatform een dubbel encoded waarde heeft.
Met MTOM nog niet geprobeerd.
Volgens mij is in het StUF Testplatform een vrij willekeurige reeks tekens opgenomen als inhoud van dit element. Als jullie hier last van hebben moeten we dat aanpassen in het StUF Testplatform.
Wij hebben hier geen last van, het was puur een observatie.
Het is wellicht handig om hier wel een realistische waarde in te zetten
Misschien moeten we conform defacto standaard voor document inhoud een Lorem ipsum gebruiken?
Ik neem aan dat je bedoelt een ge-base64-de Lorem ipsum document?
Excuses, onderdaad een base-64 encoded Lorem ipsum.