arkivverket / noark5-standard

Noark 5 versjon 5.0 – innspill før versjonering til Noark 5 versjon 5.1
Other
3 stars 5 forks source link

presedensStatus vs presedensstatus (M056) #56

Closed petterreinholdtsen closed 4 years ago

petterreinholdtsen commented 4 years ago

I følge metadatakatalog.xsd er navnet på M056 'presedensStatus' med stor S, mens samme metadatakatalogoppføring i følge tillegg A (Metadatakatalog) har navnet 'presedensstatus' med liten s. Hvilket navn er riktig? Kan de to samkjøres slik at oppføringen staves likt begge steder?

hanber commented 4 years ago

I henhold til navnereglene i noark 5 skal det være presedensstatus siden det er ett ord.

petterreinholdtsen commented 4 years ago

OK. Da har jeg laget endringsforslag som oppdaterer Noark 5-spesifikasjonen. I tillegg må XSD oppdateres.

joergen-vs commented 4 years ago

Dette ble endret til presedensStatus fordi det skulle konvensjonen i dokumentet. Alle arkivenheter [de med systemid] har liten s i status [arkivstatus, moeteregistreringsstatus..] mens andre arkivobjekter som ikke har systemID [dokumentflyt og presedens] har stor s i status [flytStatus og presedensStatus].

Skal det da også endres for flytStatus?

petterreinholdtsen commented 4 years ago

Intet syn på flytStatus, ville bare bemerke at i #52 om presedens er det forslag om å legge inn systemID til presedens.

Forresten, når ble det endret til presedensStatus, og hva var det før?

joergen-vs commented 4 years ago

Det var liten s, endret sammen ved v5.0.

hanber commented 4 years ago

Ok. Da er det nye konvensjoner som jeg ikke har hørt om. Den opprinnelige konvensjonen var som skrevet over at stor bokstav inne i et navn skulle bety at navnet består av flere ord, som i avskrevetAv. Altså at stor bokstav inne i et elementnavn hadde en mening, uavhengig av hva slags objekttype elementet blir benyttet i.

Siden metadataelementene i kan inngå i flere objekttyper (i prinsippet både med og uten systemID), er det vanskelig å knytte navnekonvensjonen til om objektet har systemID eller ikke.

Hva er den nye konvensjonen? Skal hver del av et sammensatt ord (i elementer i objekttyper som ikke har systemID) ha stor bokstav, som i rettsKildeFaktor, eller skal det være rettskildeFaktor?

Hvordan skiller man mellom objekttyper og datatyper? Er enhver complexType en objekttype? Er det i så fall slik at enhver complexType som har element systemID skal følge gammel konvensjon, mens enhver complexType som ikke har element systemID skal følge ny konvensjon? I henhold til denne regelen skal elementene i mappe følge gammel konvensjon, mens elementene i merknad skal følge ny konvensjon. Det gjør de ikke, merknad er en sekvens av merknadstekst, merknadstype, merknadsdato og merknadRegistrertAv.

Jeg synes det blir vanskeligere å forstå navnekonvensjonen hvis man skal benytte ulik navnekonvensjon avhengig av om objektet har systemID eller ikke.

Dette ble kanskje litt mye tekst om en detalj. Mitt prinsipale standpunkt er altså å endre alt til opprinnelig navnekonvensjon, men det viktigste er at skrivemåten er konsistent mellom ulike dokumenter og i ulike sammenhenger, og jeg mener XSD-ene skal være "master" for skrivemåtene.

petterreinholdtsen commented 4 years ago

[Jørgen]

Det var liten s, endret sammen ved v5.0.

Så sannelig. Endringen er ikke nevnt i endringsloggen i starten av metadatakatalog.xsd, så den har gått under radaren for min del. Ser den er omtalt som endring 18 datert 2016-12-01 i arkivstruktur.xsd:

M056 - Endret navn på type presedensstatus til presedensStatus for konsistens

Det er uklart fra kommentaren hva den skal være konsistent med.

Når jeg sammenligner master i schemas, N5/v4.0 med N5/v5.0/, ser jeg følgende navneendringer i metadatakatalog.xsd:

Det viktigste er at XSD og Noark 5-tekst er enige om navnet.

-- Vennlig hilsen Petter Reinholdtsen

joergen-vs commented 4 years ago

Bruk av stor eller liten bokstav, "Camel case", hvor hvert enkeltstående ord har stor forbokstav med mulig unntak av første ordet, og så slått sammen. Rettskildefaktor er et anerkjent ord for "en argumentkilde som brukes for å kunne løse rettslige problemstillinger", og trenger ikke "deles opp" på samme måte som "presedensGodkjentDato".

presedensDato opprettetDato opprettetAv tittel beskrivelse presedensHjemmel - dukker kun opp i arkivverkets dokumentasjon, slått sammen og stor bokstav i Hjemmel rettskildefaktor - jusleksikon.no presedensGodkjentDato presedensGodkjentAv avsluttetDato avsluttetAv presedensStatus - dukker kun opp i arkivverkets dokumentasjon, slått sammen og stor bokstav i Status

Mulig dette ikke er gjennomført i standarden, men det er standard måte å gjennomføre det på. Eksempelvis for gradering, hvor graderingsdato og nedgraderingsdato ikke finnes [i den betydningen] på fagspråket.

hanber commented 4 years ago

Helt enig i prinsippet, som er det vi opprinnelig brukte.

Med enighet om reglene, gjenstår spørsmålet om hva som er ett eller flere ord. Jeg har gått gjennom gjeldende arkivstruktur.xsd, og den ser så godt som helt riktig ut i henhold til reglene. Følgende kan imidlertid diskuteres: arkivskaperNavn -> arkivskapernavn; korrespondanseparttype -> korrespondansepartType eller korrespondansepartNavn -> korrespondansepartnavn; arkivperiodeStartDato -> arkivperiodeStartdato, jf. https://naob.no/ordbok/startdato; arkivperiodeSluttDato -> arkivperiodeSluttdato, jf. https://naob.no/ordbok/startdato. sjekksumAlgoritme -> sjekksumalgoritme presedensDato -> presedensdato, jf. kassasjonsdato, nedgraderingsdato presedensHjemmel -> presedenshjemmel, jf kassasjonsjhemmel formatDetaljer -> formatdetaljer

petterreinholdtsen commented 4 years ago

Hvis systemID er relevant for navngiving, så bør vel tillegg A del A.1 (Navn på metadataelementer) oppdateres med en forklaring på hvordan dette skal fungere?

Når det er sagt, så er det verdt å tenke på at enhver navneendring i XSD vil føre til utviklings- og testkostnader hos både produsenter og konsumenter av uttrekks-XML, slik at en bør ha gode grunner til å endre navn på en eksisterende metadatakatalog-oppføring før en påfører noen ekstrautgifter. Problemet med presedensStatus vs presedensstatus ble rapportert for å sikre at samme navn ble brukt over alt, ikke for å få en generell gjennomgang og potensiell endring av alle oppføringer i katalogen. Jeg tror nemlig det er viktig at alle deler av Noark 5 bruker identisk navn for samme ting, hvilket ikke er tilfelle for M056, der Noark 5, XSD og Noark 5 Tjenestegrensesnitt bruker ulike varianter.

-- Vennlig hilsen Petter Reinholdtsen

joergen-vs commented 4 years ago

Heller mot stor bokstav, som ser ut som konvensjonen i standarden, /*+. Fordelen er at hvert elementnavn er selvforklarende, i stedet for en forkortet form, f.eks. korrespondansepart/type, mens de som er selvforklarende ikke har med navn på arkivenhet, som tittel eller arkivdel/arkivperiodeStartDato.

For dato har man gått for å bake inn kode i variabel-navnet, i stedet for å legge det som attributt, som ville komplisert flere aspekter ved teknisk implementasjon av standarden. *Dato, som arkivperiodeStartDato eller opprettetDato. Sånn sett setter jeg heller spørsmålstegn ved M111, presedensDato. "Registreres manuelt ved opprettelse av presedens" høres likt ut som opprettetDato. presedensDato blir dermed ikke en spesifikk handling, og bryter mønsteret.

formatDetaljer er et sårt område for tiden. Personlig mener jeg det gjøres om fra rent tekstfelt til en gruppe, så man får lagt inn, vel, format-detaljene. Når det er oppdaget et spesifikt format i en analyse, kan detaljene, i form av PUID (pronom universal id) og mimetype legges inn. Forslag: ```xml Acrobat PDF/A - Portable Document Format fmt/354 application/pdf ```
petterreinholdtsen commented 4 years ago

[Jørgen]

Fordelen er at hvert elementnavn er selvforklarende, i stedet for en forkortet form, f.eks. korrespondansepart/type, mens de som er selvforklarende ikke har med navn på arkivenhet, som tittel eller arkivdel/arkivperiodeStartDato.

Forstår ikke denne fordelen, kan du utdype? Elementnavn er jo bare navn, og må jo uansett følges av en beskrivelse for at en skal vite hvordan de skal brukes. Om de heter A, X, presendensStatus eller presedensstatus har jo ikke noe å si i så måte.

Jeg diskuterer gjerne format, men den diskusjonen hører nok hjemme i en annen mangelmelding, så jeg biter ikke på diskusjonen her der temaet er presedensStatus.

-- Vennlig hilsen Petter Reinholdtsen

joergen-vs commented 4 years ago

Forstår ikke denne fordelen, kan du utdype? Elementnavn er jo bare navn, og må jo uansett følges av en beskrivelse for at en skal vite hvordan de skal brukes. Om de heter A, X, presendensStatus eller presedensstatus har jo ikke noe å si i så måte.

Jeg er tilhenger av den eldre skole, når det gjelder variabel-navn; korte og lite deskriptive, så kan dokumentasjon legges ved siden av. "Nå til dags", og funnet i Noark-standarden, ligger en del av dokumentasjon / bruk allerede i variabel-navnet, f.eks. presedensStatus. Det er ikke tvil om hvilken status dette gjelder, i motsetning til om dette elementet hadde ligget under flere objekter, arkivdel.status, saksmappe.status. Da måtte det være forklart [i dokumentasjonen] hvilket felter og hvilke verdier den bruker for hvert element den er koblet til. Men, du ville bare trengt ett statusfelt.

På samme måte kan man lage {handling type="opprettet" dato="01.01.2020"}saksbehandler{/handling} for alle typer datoer, som avhenger av person. Men da måtte man lagt inn bruken av nærmere 30 felter i dokumentasjonen, som hadde blitt rotete. Liten og effektiv kode, men vanskelig å ta i bruk.

petterreinholdtsen commented 4 years ago

[Jørgen]

Jeg er tilhenger av den eldre skole, når det gjelder variabel-navn; korte og lite deskriptive, så kan dokumentasjon legges ved siden av. "Nå til dags", og funnet i Noark-standarden, ligger en del av dokumentasjon / bruk allerede i variabel-navnet, f.eks. presedensStatus. Det er ikke tvil om hvilken status dette gjelder, i motsetning til om dette elementet hadde ligget under flere objekter, arkivdel.status, saksmappe.status. Da måtte det være forklart [i dokumentasjonen] hvilket felter og hvilke verdier den bruker for hvert element den er koblet til. Men, du ville bare trengt ett statusfelt.

Fordelen for tjenestegrensesnittet med ulike statusfeltnavn, er at ulike statustyper har ulike verdilister, og en slår opp hvilke verdier som finnes ved å slå opp listen koblet til et gitt statusfeltnavn. En kunne løst dette annerledes, naturligvis, men slik strukturen er i dag vil en ikke kunne bruke "gi meg alle lovlige verdier for 'status'"-spørringer i tjenestegrensesnittet. Det er dermed en fordel med spesielle og ikke generelle feltnavn der.

-- Vennlig hilsen Petter Reinholdtsen

petterreinholdtsen commented 3 years ago

Se #79 for forslag om å standardisere kodelister.