Ref. kommentarer ang. camelCase i annen issue fra GI: Det bør vurderes om M05x ergyldig bør hete erGyldig.

Dersom vi innfører kodelister som foreslått, eventuelt litt utvidet, bør i så fall f.eks. landkode angis med verdisett (hvilken standard det følger), siden landkoden vil være ulik for ulike objekter (som person og organisasjon) den inngår i?
Faren med dette er at det kanskje vil medføre ønske om et mer omfattende kodeverk, og vi vil nødig at kodeverket i seg selv blir en kompleks struktur.
@sturtzel: M05x bør hete erGyldig iht. våre skriveregler. Vi vil også gjøre de endringene i forslagene som må til for å få navningen på standard form.
Ad en annen kommentar om metadatanavn og standardverdier: Vi benytter norsk orddeling når vi bruker camelCase (unntatt for forkortelsen ID). Vi bruker f.eks. systemID selv om elementet burde hete systemidentifikator.

Land er i henhold til bruk i korrespondanse. D.v.s. at det er totegnsvarianten som er aktuell. Det er ikke foreslått landkode for organisasjonsid og personid selv om disse kan tagges.

Jeg oppfatter kodeverdi som det som skal inneholde den lesbare verdien av metadataelementet, f.eks. "Overlappingsperiode" som verdien av arkivdelstatus, og at det er denne verdien som avleveres, og kortkodeverdi, f.eks. "O" for "Overlappingsperiode", bare benyttes i datautveksling. Er det riktig oppfattet?
Vi må for all del unngå at kortkodeverdi brukes til oppslag i kode ved avlevering, slik at opprinnelig kodeverdi går tapt dersom denne er blitt endret etter at metadataelementet ble registrert.
Hvor i arkivstrukturen skal i så fall kode ligge? Jeg ser for meg at det må ligge direkte under arkiv.

Kortkodeverdi tilsvarer koder slik de var i Noark 4 og er benyttes for integrasjoner, oppsett etc.
Kodeverdi tilsvarer koder slik de er i Noark 5 avleveringsformat og benyttes fortsatt for dette.
Kode er et objekt på toppen av begge og vil i integrasjoner benyttes "i stedet for" kodeverdi.
Kodeverdi og kortkodeverdi henger sammen, så det vil ikke være mulig å endre den ene uten å endre den andre. I integrasjoner vil det enten sjekkes om den ene har verdi og hvis ikke om den andre har det, alternativt sjekkes begge og man får smekk på fingeren om det er avvik. Spesielt for objekter som saksbehandler og administrativ enhet er det et problem med at samme navn kan benyttes på forskjellige enheter. UID er mindre egnet for integrasjoner der det skal gjøres oppsett.

Det kan forresten være verdt å nevne forslaget i #95 om å ikke bruke en boolsk verdi for gjeldende/inaktiv/utdatert, men heller notere tidspunktet for når verdien ikke lenger er gyldig, og sammenligne med dagens dato for å finne ut om det er greit å bruke koden/navnet. Da kan kanskje M602 avsluttetDato, M604 arkivertDato, M613 slettetDato eller M630 kassertDato brukes?

Her ble det litt mange på en gang. Når det gjelder kortkode, full kode etc. har bruken i GI vært objekt med angivelse av om det er kortkode eller navn, ikke kun en tolkbar verdi slik det er i dagens avleveringsformat. Det er dette som er foreslått videreført.

GeoIntegrasjon 1.1 benytter erGyldig, arkivintegrasjon som har vært i almen bruk i snart 10 år. Jeg er enig i at man bør ha tilsvarende håndtering forskjellige steder. M6xx-feltene burde heller vært sanert da en del av de kan forekomme flere ganger, spesielt for koder og folk som kan gå inn og ut. Felt som aktiv/gyldig kan inngå direkte i et filter på en nedtrekksliste ved bruk og er derfor bedre egnet for disse enn dato fra/til. De komplette registrene har flere verdier enn id, kode, beskrivelse og datointervall. Bruken ved generisk koderegister er ikke helt den samme.

Kode slik det ligger i GI 1.1 (og som vi har foreslått for Noark) blir noe slikt (struktur, feltnavnene våre var forskjellig):

O
Opprettet
false

Det er prinsippet som er viktigst for oss og vi har foreslått ut fra bruk i tjenestegrensesnitt (men en stor fordel om det er likt mellom eForsendelse Arkivmelding, FIKS Arkiv, N5WS og avleveringsformatet).

Om det skal være dato i stedet for erGyldig, bør det være generisk gyldigFra og gyldigTil da en rolle kan settes inaktiv og så aktiveres igjen. Tom verdi må da bli "fra tidenes morgen" og "til evigheten".

Kodeobjektet med erGyldig er tenkt for å hente kodelister, ikke ved bruk i objekter. Da vet klienten om dette er en verdi for kun for visning/søk eller en verdi også for registrering.

eForsendelse Arkivmelding og FIKS Arkiv (tidligere kalt GeoIntegrasjon Arkiv versjon 2) vil få samme struktur. Ref. https://github.com/ks-no/fiks-arkiv

Behovet er for API, men som sagt er det en fordel med felles format for API og avlevering (avlevering må da ha med mer spesifikk info da spesielt personnavn kan være flertydige). Noark 5 har p.t. ingen beskrivelse av koderegistre andre steder enn i teksten (obligatoriske verdier = minimum). De lå i XSD-ene, men det medførte at de ikke kunne brukes i forbindelse med API (spesielt ikke for uferdig materiale) og dessuten som oftest måtte redigeres.

I GI 1.1 er kodelistene spesifisert. I GI 2.0 (FIKS Arkiv) så jeg at dette manglet (også i XSD-en). Status der er vel at vi avventet svar fra Arkivverket før vi gikk videre. Eksempler på kodelister finnes i http://geointegrasjon.no.

Jeg laget et utkast til endringsforslag for å beskrive slike lister over gyldige metadata-verdier. Ikke helt fornøyd med den tekstlige beskrivelsen, og tar gjerne imot forslag til forbedringer.

Ideen er å beskrive innholdet i en ny fil metadata.xml som ser noe ala dette ut:

<metadata>
  <kodeliste type="arkivstatus">
    <kodeverdi>
      <kode>A</kode>
      <kodenavn>Aktiv periode</kodenavn>
    </kodeverdi>
    ...
  </kodeliste>
  ...
</metadata>

Jeg er usikker på hvordan dette best beskrives i tillegg B.

Behovet er det samme i dag som i 2012. giFellesKodeliste20210131.xsd:

<xs:schema targetNamespace="http://rep.geointegrasjon.no/Felles/Kodeliste/xml.schema/2012.01.31" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://rep.geointegrasjon.no/Felles/Kodeliste/xml.schema/2012.01.31" xmlns:planbasisns="http://rep.geointegrasjon.no/Plan/Basis/xml.schema/2012.01.31" xmlns:planfellesns="http://rep.geointegrasjon.no/Plan/Felles/xml.schema/2012.01.31" xmlns:planutvidetns="http://rep.geointegrasjon.no/Plan/Utvidet/xml.schema/2012.01.31" xmlns:felleskontaktns="http://rep.geointegrasjon.no/Felles/Kontakt/xml.schema/2012.01.31" xmlns:fellesadressens="http://rep.geointegrasjon.no/Felles/Adresse/xml.schema/2012.01.31" xmlns:fellesgeometrins="http://rep.geointegrasjon.no/Felles/Geometri/xml.schema/2012.01.31" xmlns:felleskodelistens="http://rep.geointegrasjon.no/Felles/Kodeliste/xml.schema/2012.01.31" xmlns:fellesfilterns="http://rep.geointegrasjon.no/Felles/Filter/xml.schema/2012.01.31" xmlns:skjemabyggesakns="http://rep.geointegrasjon.no/Skjema/Byggesak/xml.schema/2012.01.31" xmlns:fellestekniskns="http://rep.geointegrasjon.no/Felles/Teknisk/xml.schema/2012.01.31" xmlns:kartbasisns="http://rep.geointegrasjon.no/Kart/Basis/xml.schema/2012.01.31" xmlns:arkivfellesns="http://rep.geointegrasjon.no/Arkiv/Felles/xml.schema/2012.01.31" xmlns:arkivkjernens="http://rep.geointegrasjon.no/Arkiv/Kjerne/xml.schema/2012.01.31" xmlns:arkivdokumentns="http://rep.geointegrasjon.no/Arkiv/Dokument/xml.schema/2012.01.31" xmlns:sakfaserns="http://rep.geointegrasjon.no/Sak/Faser/xml.schema/2012.01.31" xmlns:sakskjemans="http://rep.geointegrasjon.no/Sak/Skjema/xml.schema/2012.01.31" xmlns:matrikkelfellesns="http://rep.geointegrasjon.no/Matrikkel/Felles/xml.schema/2012.01.31" xmlns:matrikkelutvidetns="http://rep.geointegrasjon.no/Matrikkel/Utvidet/xml.schema/2012.01.31" xmlns:matrikkelbasisns="http://rep.geointegrasjon.no/Matrikkel/Basis/xml.schema/2012.01.31" elementFormDefault="qualified" version="2012.01.31 - GeoIntegrasjon v1.1.0">
<xs:element name="KodeListe" type="tns:KodeListe"/>
<xs:complexType name="KodeListe">
xs:sequence
<xs:element name="liste" type="tns:Kode" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Kode" type="tns:Kode"/>
<xs:complexType name="Kode">
xs:sequence
<xs:element name="kodeverdi" type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="kodebeskrivelse" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="erGyldig" type="xs:boolean" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

Vi hadde ikke typeangivelse der siden kodelistene ble returnert basert på tjeneste om å hente en kodeliste med et angitt navn.

Når det gjelder attributtnavnene kan tittel være et bedre navn enn kodebeskrivelse. Om kode er et bedre navn enn kodeverdi er jeg litt mer usikker på, spesielt siden objektet i seg selv heter Kode.

Hvis man har typefeltet blir unødvendig. Det er 10 år siden vi definerte GI, men jeg tipper at generisk kode som objektnavn gjorde at man kunne bruke én tjeneste for å hente og at definisjonene ble enklere.

Dato fra/til gir flere muligheter enn "gyldig", men er lite relevant for en klient (mer relevant for avlevering).

Jeg mener at det var Tor Kjetil som modellerte GI i sin tid og at det var han som også modellerte N5WS. Men uansett mener jeg det var en glipp av N5WS å ikke ta utgangspunkt i GI (uten å følge den slavisk - bl.a. objektet Kontakt i GI ble altfor komplisert).

Det hadde ellers vært en fordel om flere deltok i diskusjonene... Dessuten litt lett å overse noe når man bare har diskusjonen på en liten skjerm.