Ønske om generisk støtte for valgfri metadata knyttet til dokumenter

[aberner]

Det er ønskelig at postkasseleverandørene kan utvikle og tilby støtte for verdiøkende tjenester. Postkasseleverandøren bør kunne tilby denne funksjonaliteten uten at dette koordineres med Difi nødvendigvis og imellom begge postkasseleverandører.
utvidet funksjonalitet/verdiøkende tjenester er i stor grad avhengig av at avsender sender med noe strukturerte data sammen med forsendelsen. Disse strukturerte dataene kan variere, fra behov til behov.
Eksempler på slike behov se referanser lenger ned.

I dagens grensesnitt så valideres alle dokumentpakker som mottas av postkasseleverandørene strengt.
Dersom dokumentpakkene har innhold som postkasseleverandøren ikke kjenner blir hele forsendelsen avvist.

Det er ønskelig at det utvikles en generell støtte for at dokumentpakker kan inneholde strukturerte metadata i form av xml-filer som. Dersom postkasseleverandør mottar slike strukturerte metadata skal postkasseleverandør enten behandle metadataene (fordi de er kjent) eller ta mot og ignorere metadataene.

metadataene foreslåes implementert på følgende måte:

<hoveddokument id="hoveddokument" href="dokument.pdf" mime="application/pdf">
	<tittel lang="no">Dokument til innbygger</tittel>
</hoveddokument>
<vedlegg href="strukturert_metadata.xml" mime="application/vnd.unik.mimetype+xml" utvider="hoveddokument" />

Her bruker postkasseleverandøren: utvider for å avgjøre om dette er en valgfri utvidelse eller ikke. Når denne eksisterer skal postkasseleverandøren ikke avvise meldingen selv om mime skulle være ukjent.
Postkasseleverandøren bruker mime for å finne ut hvilken type metadata dette er.

Dette er en generell løsning som gir postkasseleverandøren fleksibilitet til å realisere følgende saker:

#193
#187
#198

---

En problemstilling som dette forslaget ikke berører eller løser er hvordan avsender skal få oversikt over hvilke valgfrie utvidelser hver enkelt postkasseleverandør støtter og hvordan disse skal brukes.
Det bør diskuteres for å evaluere om det må være en forutsetning før man kan lage denne løsningen.
jeg anser at det ikke er avgjørende og dermed ikke nødvendigvis må være påplass for å få utført denne endringen.

[aberner]

forslag til prinsipper for funksjonaliteten:

• må ignorere ukjente utvidelser
• må lagre og videresende ukjente utvidelser
• åpen publisert informasjon om utvidelser
• forutsigbarhet for leverandører i markedet i forhold til nye utvidelser
• basert på åpne standarder der det er relevant

[marnormic]

noterte meg også følgende konkretiseringer

• anvisninger fra standardiseringsrådet skal følges
• bruk av generiske løsninger fremfor virksomhetsspesifikke

Derutover følgende omkring implementering:

• Difi skal ha ting til innsyn og godkjenning
• tilgjengelig 3. mdr før produksjon
• fastlagt responstid hos de respektive leverandører

[tor-kleiberg]

For å ivareta god brukeropplevelse og UX, så ønsker vi i Digipost å begrense metadata per dokument til maks 1.

Vi ser derfor, nå, for oss at metadata bør angis på følgende måte:

<hoveddokument id="hoveddokument" href="dokument1.pdf" mime="application/pdf">
	<tittel lang="no">Dokument til innbygger</tittel>
	<metadata href="strukturert_metadata_1.xml" mime="application/vnd.unik.mimetype+xml"/>
</hoveddokument>
<vedlegg id="vedlegg" href="dokument2.pdf" mime="application/pdf">
	<tittel lang="no">dokument</tittel>
	<metadata href="strukturert_metadata_2.xml" mime="application/vnd.unik.mimetype+xml"/>
</vedlegg>

[kjorlaug]

Blir litt filosofisk - men strengt tatt så er det då forskjell på metadata (som skildrar data) og data. Dokumentet (hoveddokument og vedlegg-elementa) er i ditt eksempel pdf-dokument, i praksis ein "visning" av informasjonen i (meta)data-elementet. Visninga er formelt sett ustrukturert og ikkje maskinlesbar, medan (meta)data-fila er strukturert og maskinlesbar.

Så poenget er vel at det ser heilt greitt ut - bortsett frå at elementet bør heite <data>, ikkje <metadata>, for å signalisere at det skal vera strukturert/maskinlesbar versjon av meiningsberande innhald i dokumentet :)

[sindrebn]

Ser ut som det forsvant et par ord fra kommentaren din @kjorlaug . Antar det skulle være litt tekst foran kommaene i setningen sitert under :)

(…) elementet bør heile , ikkje , for (…)

[kjorlaug]

Mangla escape på xml-elementet - var ikkje lett å lese utan :)