ZKN03.10: EDC Kennisgeving; Ondersteuning attributen bij element 'inhoud'

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

4 reacties / 0 nieuw
Anoniem
ZKN03.10: EDC Kennisgeving; Ondersteuning attributen bij element 'inhoud'

Sectormodel ZKN03.10: Wat is de reden dat bij het element 'inhoud' onder een EDC kennisgeving 'xmime:contentType' en 'StUF:bestandsnaam' als attributen worden ondersteund?

In mijn ogen wordt contentType (MIME-type) al met het reguliere element 'formaat' afgedekt en moet er ook een regulier attribuut worden ondersteund voor 'bestandsnaam'.

Op die manier kunnen de attributen vervallen.

Maarten van den...

Deze attributen worden op het StUF-type voor binaire inhoud voorgeschreven, opdat dit type ook gebruikt kan worden zonder dat elders in de entiteit elementen hiervoor moeten worden opgenomen. Binnen EDC zijn de elementen opgenomen om deze waarden ook te kunnen communiceren als de EDC geen binaire inhoud bevat. Binnen EDC leidt dit inderdaad tot redundantie, maar ik betwijfel of dat een probleem is.

Anoniem

In de StUF Expertgroep Informatiemodellen heb ik laatst voorgesteld om het element 'formaat' logisch gezien verplicht te stellen. Het lijkt me voor leveranciers uiteindelijk duidelijker als het mime-type altijd via het element 'formaat' doorgegeven moet worden, hierdoor het voorstel om het attribuut bij 'inhoud' ook te laten vervallen. Wat is bijvoorbeeld het werkelijke mime-type indien beide met een afwijkende waarde gevuld zijn (zowel het attribuut als het reguliere element).

Daarnaast is het op dit moment voor PRLG complex om StUF-attributen te mappen naar een tabel. Voor reguliere elementen is dat geen probleem.

Maarten van den...

Ik kan me voorstellen dat je binnen EDC een en ander logischer vindt, maar ik blijf zitten met het probleem dat bij de afhandeling binnen MTOM het verreweg het eenvoudigste is, wanneer het element waarin de inhoud zit het mimeType en de bestandsnaam bevatten, omdat de afhandelaar op die manier altijd weet waar hij deze gegevens moet zoeken. Het lijkt me niet wenselijk om voor alle implementaties van binaire bijlagen voor te schrijven dat naast het element met als type StUF:BinaireInhoud ook nog een element met een voorgeschreven elementnaam en een voorgeschreven type beschikbaar moet zijn.

Opname als attributen binnen StUF:BinaireInhoud maakt het vinden van deze informatie voor MTOM afhandelaars eenduidig.