-
Notifications
You must be signed in to change notification settings - Fork 1
Møte 7. mai 2018
Presentasjon : https://docs.google.com/presentation/d/1-5BVrZhM8UhM85Fd2IuOzNgbEdqusvQqaN5wL_sML5Y/edit?usp=sharing
09:00 - 10:00 Program
10:00 - 10:10 Kaffe
10:10 - 11:00 Program
11:00 - 11:10 Kaffe
11:10 - 12:30 Program
Gjennomgang av skisse og XSD. Flere kommentarer og forslag til endringer. Dokumenter som issue her på github.
Det ene xml eksempelet er ufullstendig. Difi skal utbedre.
UUID må være type 1,2 eller 4. Versjon 3 og 5 (kompositt og hashbasert) blir kun for historiske data. For å lette overgangen så vil einnsyn-klienten få en tabell for mapping til UUID for de som ønsker dette. Primært for noark 5 xml.
Ingen UUID på klasse eller klassifikasjon. Beholdes på arkiv og arkivdel.
Ingen behov for å ivareta rekkefølgen som saker blir satt opp i et møte. Det blir tre felter for saksnummer for møte.
Api på eInnsyn for å finne en UUID, ved bruk av foelgsakenreferanse. APIet kan brukes av arkivsystement for å lage et GUI for å koble en en saksframlegg-journalpost til en eksisterende en på eInnsyn på tvers av arkivsystem.
Gjennomgang av XSD og XML. Skal ta en avsjekk med Oivind i arkivverket angående namespace.
Blir ikke flere felt enn systemID. Det er ikke nevnt på møtet, men det blir naturligvis også en json-lyd variant av trekke-tilbake-meldinger.
Trekke-tilbake skal skje når noe som ikke kan overskrives skal fjernes fra eInnsyn. Man trenger ikke å trekke tilbake for å fjerne ett fulltekstpublsert dokument, her kan journalposten publiseres på nytt uten dokumentobjektet/beskrivelsen.
Trekke-tilbake meldinger skal kun forekomme der noe skal fjernes fra eInnsyn, f.eks. hvis en sak ikke skal tas opp i et møte likevel. Hvis det sendes meldinger for alt i et møte, for å kunne republisere hele møtet, så vil dette ødelegge for abonnere-på-søk for sluttbrukerne; de vil få e-post med nye treff hver gang møtet da blir republisert.
Det blir behov for en løsning som kan håndtere både gammel og ny ID fremgangsmåte, slik at man kan gå over til å levere alternativ én med UUID for de som har levert alternativ én i dag. DIFI må utrede mer.
Det ble enighet om datamodellen for møte, men med forbehold om at justeringer må være mulig etterhvert som man tar den i bruk.
Følgende issues må løses i XSDen:
Behov for valideringstejenste og test einnsyn system. Også tydelig behov for å vite hva som skjer etter opplasting, følge prosesseringen og tilbakemelding tidlig om feil.
Ikke behov for konverteringstjeneste.
Som på Slides. Arkivlevernadørene indikerer implementasjon påbegynt tidligst på høsten.
Også noe diskusjon om andre kommuner, KS, og svar-ut.