Wij willen dat de DCV de bestandsnaam voor een te creëren document opgeeft. In de DCR 1.1 specificatie vind ik echter niet terug hoe dat kan.
In het bericht 'verzoekStartenDocumentcreatieDi02' had ik binnen 'IsSpecificatieVan.gerelateerde.document' (zie p. 26) als mogelijk element 'Bestandsnaam' verwacht, zoals ook in het Informatiemodel Documentcreatie is opgenomen als onderdeel van Documentspecificatie (p. 13), gebaseerd op RGBZ 1.0.
Ook in de testberichten van DCR 1.0 tref ik bestandsnaam niet aan in de verzoekberichten.
Hoe zit dit?
Het attribuut bestandsnaam staat in RGBZ 1.0 als volgt gedefinieerd:
Veelal zal de Documentinhoud uitgewisseld worden in de vorm van een fysiek bestand. De naam daarvan valt af te leiden uit de combinatie van Documenttitel en Documentformaat, gescheiden door een punt. Niet altijd is de zender van een bericht waarin het beoogd is de documentinhoud te leveren, in staat het formaat te bepalen. In dat geval wordt expliciet de naam van het bestand genoemd waarin zich de documentinhoud bevindt. De voorwaarde is dat de ontvanger uit de bestandsnaam het formaat kan afleiden.
De bestandsnaam is dus samen te stellen uit de attributen titel en formaat. Deze twee attributen kunnen wel meegenomen worden in het EDC-basis complextype wat gebruikt is in de DCR berichten.
Ik had gehoopt buiten 'formaat' en daarmee ook uit de mogelijke onduidelijkheid daarover (zie https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/rgbz/gebruik-van-veld-formaat-bij-een-document-informatieobject) weg te blijven. Of 'formaat' gebruikt kan worden voor de bestandsnaam, betwijfel ik. In RGBZ 1.0 wordt aanbevolen om hiervoor MIME-types te hanteren, en in RGBZ 2.0 is dat tot standaard verheven (DCR 1.1 is gebaseerd op RGBZ 1.0, maar we kijken graag vooruit). Dus niet bijv. 'docx' maar 'application/vnd.openxmlformats-officedocument.wordprocessingml.document', en niet 'pdf' maar 'application/pdf' als formaat. Niet te gebruiken dus om achter de punt te zetten c.q. als extensie te gebruiken.
Verder: in deze RFC (https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/koppelvlak-dcr/rfc-metadata-opgegeven-door-dcv-opnemen-antwoord-bericht) lees ik over het in een antwoordbericht teruggeven van de DCV opgegeven metadata. Als voorbeeld bij die metadata is bestandsnaam (niet: titel, formaat) opgenomen. 't Is twee jaar geleden: is dat inmiddels niet meer valide?
Beste Jacob,
Het is mooi te zien dat je goed rondkijkt op het discussie forum. Echter, de koppelvlakken zijn gebaseerd op een onderliggend informatiemodel, in dit geval het RGBZ 1.0.
In de eerste discussie die je aanhaalt wordt gesproken over hoe eea. in RGBZ 2.0 (de volgende versie dus, die op dit moment verstuft wordt) zal gaan worden.
De huidige koppelvlakken zijn gebaseerd op RGBZ 1.0. Het attribuut formaat staat hier beschreven en kent de volgende definitie:
Het gaat hier om het bestandsoort van het enkelvoudig document, zoals ‘pdf’, ‘odf’, ‘xml’, ‘gml’, etc. Het betreft het Dublin Core metadata-element ‘Format’ met als toelichting: Typically, Format will include the media-type or dimensions of the resource. Format may be used to identify the software, hardware, or other equipment needed to display or operate the resource. Examples of dimensions include size and duration. Recommended best practice is to select a value from a controlled vocabulary (for example, the list of Internet Media Types (MIME) defining computer media formats).
In de tweede discussie die je aanhaalt wordt inderdaad formaat als voorbeeld van een metadataveld genoemd. Dit is inderdaad een foutief voorbeeld, helaas. In de specificatie van de Documentcreatieservices versie 1.1 staat op pagina 25 een tabel met de door de werkgroep vastgestelde metadata welke door een DCA geretourneerd moeten worden indien deze door de DCV aangeleverd worden.
Over het algemeen kan ik je adviseren eerst op GEMMA Online in de specificaties van de standaarden te kijken en voorbeelden uit discussies niet als waarheid aan te nemen. Dat voorkomt een hoop onduidelijkheid.
Hallo Michiel,
Bedankt voor je response. Wees er overigens van verzekerd dat ik de standaarden doorzocht heb! En het is me duidelijk dat diverse discussies op dit forum over RFC's gaan.
Terug naar mijn initiële vraag, waarop met de huidige versies van de (koppelvlak) standaarden geen voor mij bevredigend antwoord mogelijk is. Want:
1. Expliciet een toe te kennen bestandsnaam meegeven, staat niet in de DCR 1.1 specificatie.
2. Bestandsnaam-exclusief-extensie gelijkstellen aan documenttitel is niet altijd gewenst.
3. Extensie gelijkstellen aan 'formaat' (RGBZ 1.0, maar ook RGBZ 2.0 als we naar de toekomst kijken) is niet correct gezien de aanbevolen best-practice (RGBZ 1.0) en de gehanteerde waardenverzameling MIME-types (gedefinieerd door IANA) (RGBZ 2.0). De extensies die in RGBZ 1.0 als voorbeelden zijn gegeven in de toelichting op 'formaat' zetten de lezer feitelijk op het verkeerde been. Het is goed dat ze in de 2.0 spec zijn weggelaten.
De oplossing waaraan ik voor ons geval (een waterschap, we volgen GEMMA-standaarden waar mogelijk) denk, is door in het verzoekbericht voor documentcreatie het groepsattribuut 'bestandsnaam' op te nemen zoals in RGBZ 2.0.
Beste Jacob,
De reden dat het attribuut bestandsnaam niet opgenomen is in de DCR standaard is simpelweg: dit attribuut is niet als element opgenomen in het complexType EDC (enkelvoudig document) uit het onderliggende sectormodel StUF ZKN. Dit omdat in de omschrijving van het attribuut bestandsnaam beschreven staat dat de bestandsnaam afgeleid kan worden door de documenttitel en het formaat (zoals beschreven in het RGBZ 1.0 is dit een extensie) te concateneren.
Persoonlijk zou ik er eerder voor pleiten om een nieuwe versie van de DCR standaard op basis van het RGBZ 2.0 te realiseren. Dat is dan denk ik gelijk de goede oplossing in plaats van een pleister te plakken die niet volgens het onderliggende informatiemodel is en ook niet terug komt in het onderliggen sectormodel StUF ZKN.
Mocht een partij dan nog met een oudere versie van Documentcreatieservices de bestandsnaam willen uitwisselen kan altijd een extra element gebruikt worden. Daar is geen nieuwe versie van de standaard voor nodig.
Mag ik je wensen meenemen in de werkgroep als argumenten om zo snel mogelijk een nieuwe versie van de DCR standaard te kunnen realiseren op basis van RGBZ 2.0? Want het is niet dat ik het niet met je eens ben of je niet ter wille wil zijn, ik heb eenvoudig weg niet de mogelijkheid om "even" een elementje toe te voegen, hoe valide de reden ook is.
Of nog beter, zou je mee willen doen met de volgende werkgroep bijeenkomst op 28 juni aanstaande? Die staat in het teken van de doorontwikkeling van de Documentcreatieservices. Mogelijk heb je nog andere wensen of bevindingen die dan gelijk met de werkgroep besproken kunnen worden?
Hallo Michiel,
Een nauwkeurig proces om te komen tot nieuwe versies van standaarden is van belang, dus even een elementje toevoegen is ook niet wat ik van je verwacht! Maar met je expertise kun je ons misschien wel de beste pleister aanreiken om een bestandsnaam mee te geven in DCR 1.1 (anders dan middels 'titel' en 'formaat'). Want ja, een nieuwe versie van de DCR-standaard zou goed zijn, maar in afwachting daarvan willen we al wel verder.
Op je vraag kom ik terug.
Hoe we het hebben opgelost.
We vereisen bij de DCA geen kennis van de bestandsnaam voor het gecreëerde document (informatieobject). In de constructie die we implementeren wordt het gecreëerde informatieobject altijd door de DCA aan de DCV geretourneerd. Dus de DCA stuurt het bijv. niet door naar een DMS (waarbij er in zo'n geval behoefte is aan de bestandsnaam waaronder het gearchiveerd moet worden). Het is de DCV de bij het gecreëerde informatieobject de bestandsnaam invult.
Bedankt voor je terugkoppeling. Sec gezien is deze oplossing dus buiten de documentcreatieservices om geregeld. Op zich prima maar het wijst mij wel op een lancune in de optionele varianten #1 Opslag door DCA in DMS via Zaak- en Documentservices en #2 Opslag in DCA in overig DMS. Nl. het ontbreken van een bestandsnaam om het bestand ook daadwerkelijk op te kunnen slaan in een DMS. De vraag is echter of het wel een probleem is.
Sterker nog, optionele variant #1 maakt gebruik van de Zaak- Documentservices om het bestand op te slaan in een DMS. Ook hier wordt geen bestandsnaam meegegeven. Dit is de eerste keer dat het ontbreken van de bestandsnaam in StUF ZKN een probleem zou zijn voor opslag van documenten in een DMS.
Ik ga dit ook in het Zaak- Documentservices forum opnemen en zie wel een agendapuntje voor de bijeenkomst van 28 juni.