You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Kopierer inn her det som stod på siden "Eksempel-forenklet:-inkludere-klassering".
Det er bedre å håndtere det videre som et issue.
Fra wiki:
Avklaringer
klasse vs nasjonale identifikatorer.
vurdere enum på denne personidentifikatorType = "F".
vurdere type også for organisasjonsnummer. Da vil modellen kunne støtte også utenlandske.
vurdere om f.eks. offentlighetsvurdertDato trengs.
bruk av UUID i referanser vs. "initialer", ref. administrativ enhet.
vurdere om objektet skal hete fødselsnummer, organisasjonsnummer etc. eller i stedet ID-nummer som objekt med type og nummer. Da kan det enkelt utvides uten at klienten trenger å vite om endringene.
hvordan vite om en adressat er person eller organisasjon (ut over at ID-nummeret gir hint). Personnavn må tagges i eInnsyn da de ikke skal være søkbare i mer enn et år. Mulighet for å angi navn som personnavn eller organisasjonsnavn? Personnavn med mulighet for å skille for- og etternavn i stedet for regler om siste ledd er etternavnet?
Kommentarer:
Ragnar Sturtzel klasse vs. nasjonale: Utfordringen er når klassen er en nasjonal identifikator. Det er neppe aktuelt med en strukturert klasse, men skriveregler kan standardiseres som f.eks. knr-gnr/bnr og at fnr og orgnr skal skrives uten blanke. Nasjonale identifikatorer bør ideelt være uavhengig av klasse også når klasseringen er på objekt. Da får det heller bli duplikat informasjon. Bruksområdet er forskjellig!
Ragnar Sturtzel enum: Enum betyr ofte at programvare må oppdateres ved utvidelser. Og en enum sier ikke nødvendigvis så mye mer enn en kode. Dokumentasjon er dog nødvendig. Det bør legges til rette for flere typer enn fødsels- og D-nummer. Hva med utenlandske?
Ragnar Sturtzel offentlighetsvurdert dato: Denne bør kuttes i den forenklede modellen da arkivet gjerne setter den automatisk. I Noark 4 var dette regulert via spesiell tilgangskode XX som sa "ikke vurdert ennå". Alt annet ga "er offentlighetsvurdert".
Ragnar Sturtzel UUID vs. initialer: Samme problemstilling for saksbehandler. Det bør vurderes å bruke objektet Kode. Da kan enhet gis navn (beskrivelse) og kode. UUID er lite hensiktsmessig da denne ikke vil være støttet på tvers av systemer og er lite lesverdig. Koder i et hierarki er mer lesverdig, fantes allerede i Noark 3, men er i stadig mindre bruk i systemer der man velger i stedet for at man taster inn. Kandidat for referansegruppe?
Kopierer inn her det som stod på siden "Eksempel-forenklet:-inkludere-klassering".
Det er bedre å håndtere det videre som et issue.
Fra wiki:
Avklaringer
Kommentarer:
Eksempel
The text was updated successfully, but these errors were encountered: