Dit is gerelateerd aan: https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/rgbz/gebruik-van-veld...
In de voegZaakDocumentToe operatie haal ik de volgende informatie uit de tabel (paragraaf 4.2.4.2):
| Stuf-ZKN-Elementen | RGBZ-attribuut | v/o |
|---|---|---|
| object.formaat | Documentformaat | v |
| object.inhoud@xmime:contentType | MimeType | o |
Documentformaat is metadata en wat mij betreft geen "technisch veld". Ik stel voor om in dit veld de "human-readable" waarde te plaatsen. Het contentType van de inhoud zou verplicht moeten gesteld worden en gevuld met een geldige waarde uit de IANA lijst (http://www.iana.org/assignments/media-types/media-types.xhtml). Het mimetype is enkel voor de inhoud van het document belangrijk en niet op metadata vlak. Sterker nog, in RGBZ 1.0 is het geen attribuut.
De mapping naar het CMIS attribuut in de tabel (paragraaf 5.3) is bijgevolg mijns inziens ook verkeerd.
| CMIS-property-id | Property van objecttype |
RGBZ-attribuut | v/o |
|---|---|---|---|
| cmis:contentStreamMimeType | EDC | Documentformaat | v |
Het veld cmis:contentStreamMimeType zou gevuld moeten worden met de waarde van contentType van de inhoud. Op technisch vlak moet binaire content namelijk altijd beschreven zijn met bestandsnaam en mimetype. Voor Documentformaat zou dan een nieuw CMIS veld gedefinieerd moeten worden in de CMIS repository indien de "human-readable" waarde ook wenselijk is.
Deze vraag is geregistreerd onder nummer 405509
Roxit is het helemaal eens met Björn.
PinkRoccade is het ook eens met het voorstel van Björn.
We moeten mimetype en formaat niet meer vermengen. Mimetype is inderdaad sowieso verplicht en formaat is soms handig (dus optioneel). De applicatie die een document creëert zou in mijn ogen de waarden van deze elementen moeten bepalen.
Ik vind het voorstel ook goed. In de CMIS specificaties (http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html ) vind ik echter geen geschikt veld om het Documentformaat (human readable) in te zetten. Zie ik iets over het hoofd? Zo niet wil ik Björn vragen om een voorzet.
Ik stel voor om in de XLSX (BIJLAGE-mapping-cmis-properties-rgbz-attributen.xlsx) de bestaande property "cmis:contentStreamMimeType" de naam "Documentformaat" te geven en de property "cmis:contentStreamMimeType" onderaan de lijst opnieuw toe te voegen als property met een mapping naar contentType.
Björn,
Ik zie geen bijlage maar als ik je goed begrijp wil je "Documentformaat" niet in een bestaande CMIS property opnemen maar in een eigen (ZS-DMS) property?
In het RGBZ 1.0 is bij de attribuutsoort Documentformaat aangegeven dat dit de XML-tag 'formaat' betreft oftewel het StUF-ZKN-element 'formaat'. Bij de verStUFfing is het element 'formaat' gecreeerd en het subelement 'mimeType' toegevoegd. Verzuimd is aan te geven op welk RGBZ-attribuutsoort dit 'mapt'. Dat heeft tot verwarring geleid.
In het RGBZ 2.0 is de attribuutsoort Bestandsnaam.Extensie toegevoegd met als XML-tag 'bestandsnaam.extensie'. Het laatstgenoemde attribuutsoort heeft als waardenverzameling "... een aanduiding van het bestandsformaat. Bij Windows-bestanden is dit de, meestal drieletterige, code na de meest rechtse punt." Oftewel vermeldingen als "doc" en "pdf". Het attribuutsoort Formaat heeft als definitie "De code voor de wijze waarop de inhoud van het ENKELVOUDIG INFORMATIEOBJECT is vastgelegd in een computerbestand." en als waardenverzameling "MIME-types en –subtypes conform IANA". Dit komt m.i. overeen met het subelement MimeType in StUF maar heeft als XML-tag nog 'formaat'. Maar dat element heeft m.i. geen nut meer nu er al een subelement MimeType is en een element 'extensie'.
Ik stel dan ook voor om het RGBZ-2.0-attribuut Formaat de XML-tag 'inhoud/@contentType' te geven oftewel te 'mappen' op het gelijknamige StUF-element en het StUF-element 'formaat' te laten vervallen (in StUF-ZKN 3.20). Hiermee ware in de nu actuele services al vast rekening mee te houden.