Met betrekking tot de mapping van RGBZ EDC attributen met CMIS properties suggereert Centric ons:
Documentformaat is een bestand extensie en dat is niet gelijk aan een mimetype. cmis:contentStreamMimeType kan niet worden gevuld met het documentformaat. Bovendien is de maximale lengte van het documentformaat 10 in RGBZ. Een mimetype kan langer zijn. Bijvoorbeeld de extensie .docx heeft mimetype “application/vnd.openxmlformats-officedocument.wordprocessingml.document”. In het edcLk01 StUF bericht kan het mimetype worden meegegeven in het contentType attribuut van het Inhoud element.
In RGBZ is beschreven dat het attribuut documentformaat een extensie kan zijn, maar ook dat er volgens de Dublin core bij voorkeur een gecontroleerde lijst gebruikt moet worden. De exacte beschrijving van dit attribuut is:
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).
Ondanks de onjuiste opvatting over het RGBZ attribuut documentformaat, is de bevinding dat de lengte in RGBZ maximaal 10 karakters is, correct. Dat is veel te kort voor het mimetype. In het meest recente concept voor RGBZ 2.0 wordt dit veld verlengd naar AN85, wat zeker lang genoeg zou moeten zijn.
Voor ons als werkgroep rest nu de vraag hoe we dit vooruitlopend op de nieuwe RGBZ 2.0 op gaan lossen. We hanteren binnen de werkgroep het uitgangspunt dat we niets oplossen dat in de nieuwe RGBZ opgelost gaat worden. Hoewel dit issue daar ook onder valt, moeten we wel verder kunnen tot die oplossing voor handen is.
Daarom vernemen wij bij KING graag uw mening over dit issue (en de suggestie van Centric), eventuele momenteel gehanteerde workarounds, et cetera. Gezien de relatie met de volgende major release van RGBZ en de zorgvuldigheid waarop we met daarop vooruitlopende aanpassingen om willen gaan, verwachten we dat dit wellicht niet in de april release van Zaak- Document services opgenomen kan worden (tenzij er direct eensgezindheid is over een te kiezen oplossing).
In de StUF schema's is dit element sinds enige tijd al wel AN85. Laten we dat gewoon al toepassen dan.
Voorstel: veld formaat voorlopig blijven vullen met extensie (want dat gebeurt nu ook). Pas in volgende major release van de standaard (aanstaande september?) eventueel over op mimetype, zodat we tijdig kunnen aanpassen. Liever zien we dat we voor Stuf afspreken het veld formaat met extensie te blijven vullen.
Zoals Dennis terecht aangeeft is het element in de StUF-ZKN schema's al geruime tijd 85 posities lang. Ik weet het niet zeker maar ik vermoed dat dat destijds al is gedaan omdat men inzag dat het formaat in RGBZ een mimetype moet zijn en geen extensie. De definitie in RGBZ is voor tweeerlei uitleg vatbaar. Ik vraag me af of Johannes gelijk heeft als hij zegt dat het veld nu wordt gevuld met de extensie. Ik heb het vermoeden dat er meer implementaties werken met het mimetype dan met de extensie. De Zaak-en documentservice specificaties hoeven op dit punt niet te worden aangepast. Het woord extensie komt niet voor in de specificaties. Het enige dat in de specificaties wordt aangegeven is dat het element documentformaat moet worden gemapped op cmis:contentStreamMimeType. Daaruit vloeit voort dat het element documentformaat tevens een mimetype dient te bevatten. En dat is iets dat (naar verwachting) in RGBZ 2.0 ook expliciet zal worden aangegeven. We zouden eventueel in de volgende release kunnen opnemen dat service providers het attribuut contenttype moeten gebruiken als dat voorhanden is en anders een mogelijk in het element documentformaat aangeleverd extensie moeten omzetten naar een contenttype. Die mapping is formeel niet goed te maken, maar in de praktijk zal dat voor de door de gemeente gebruikte extensies waarschijnlijk wel lukken.
In het RGBZ 2.0 (goedgekeurd, nog niet vastgesteld) is de attribuutsoort 'Formaat' nu van het type 'string' met als waardenverzameling "MIME-types en –subtypes conform IANA". Zie voor verdere beschrijvingen van dit attribuutsoort en de overwegingen, het Wijzigingsvoorstel RGBZ 2.0, par. 2.4.1.
Zie ook de discussie 'Gebruik van veld Formaat bij een document (InformatieObject)' over de 'mapping' van de attribuutsoort Formaat op het element 'inhoud/@contentType' in RGBZ 2.0.