II Vedlikehold/ C Import/eksport

[Ole Bjørn Darrud]

II-C1 Eksport gedcom; kan velge hvilke personer som skal med?
Forklaring: Programmet tillater at det gjøres et utvalg. Dette trenger ikke nødvendigvis være en del av selve eksportrutinen. Her bør det være mulig å gjøre separate valg:a) forfedre/etterkommere i direkte linjeb) + barneflokkerc) + inngifterd) + halvsøsken og inngifterDet må være tydelige forklaringer til hvilke relasjoner som inkluderes ved de forskjellige valgene.
Poeng: 4= a, b, c, d, 3= a, b, c, 2= a, b, 1= a, det gis et tillegg på 1 poeng dersom utvalget kan suppleres med enkeltindivider.

II-C2 Eksport gedcom; kan velge hvilke hendelser som skal med?
Forklaring: Programmet gir bruker mulighet til å velge hvilke brukte hendelser i databasen som skal være med.
Poeng: 5= OK, 2 ved begrensede valgmuligheter

II-C3 Eksport gedcom; kan velge tegnsett ANSI eller ANSEL?
Forklaring: Det er ANSEL som er Gedcoms ”offisielle” tegnsett. Det er flere utviklere som ikke bryr seg så mye om dette. Derfor er det en fordel om programmet kan generere ”flest mulig” typer tegnsett.
Poeng: 5= ANSEL + 3, 4= ANSEL + 2, 3= ANSEL + 1, 2= 3 uten ANSEL, 1= 2 uten ANSEL

II-C4 Eksport gedcom; kilder?
Forklaring: (1 p) kommer alle hovedvariablene (Forfatter, tittel, utgivelsesår, Kortnavn..) med?, (1 p) Kommer kildedetaljene med?, (1 p) Kommer kvalitetsindikator (0-3) med?, (2 p) Kommer begge kildene på person 14, dåp2 med? Program som ikke har for eksempel kvalitetsindikator skal ikke trekkes for manglende informasjon i eksportfilen.
Poeng: Ref over.

II-C5 Eksport gedcom; navn/personer?
Forklaring: (3 p) kom alle personene med?, (2 p) kommer flere alternative navn (NB likt format som hovednavn (NAME)? For program som tilfredstiller 1-A1: Kommer etternavn korrekt med? Her bør programmet tydelig gjøre oppmerksom på og gi mulighet til å bestemme hvordan slike 3 leddede navn skal behandles ved eksport. Dersom det er a) uklarhet/lite informasjon om hvordan dette behandles eller b) dette kommer feil i gedcom kan det for slike program trekkes inntil 2 poeng. Program som ikke har mulighet for å legge inn flere navn skal ikke trekkes for manglende informasjon i eksportfilen.
Poeng: Ref over.

II-C6 Eksport gedcom; hendelser?
Forklaring: (3 p) Kom følgende hendelser med (alle må med for å få poeng): fødsel (BIRT), dåp (BAPM/CHR), konfirmasjon (CONF), død (DEAT), yrke (OCCU), (1 p) kommer hendelser av samme slag med?, (1 p) Kommer ”ukjente” hendelser med ved hjelp av ”EVEN/TYPE” Program som ikke har for eksempel mulighet til å legge inn nye/egne hendelse skal ikke trekkes for manglende informasjon i eksportfilen.
Poeng: Ref. over.

II-C7 Eksport gedcom; relasjoner?
Forklaring: (2 p) kommer hendelsen ekteskap (MARR) med?, (1 p) kommer hendelsen forlovelse (ENGA) med?, (2 p) kommer hendelsen ”ikke-gift” med? (Dersom dette forholdet eksporteres med MARR skal det gis 0 poeng.)Program som ikke har for eksempel mulighet til å legge inn egne hendelser knyttet til parforhold skal ikke trekkes for manglende informasjon i eksportfilen.
Poeng: Ref over.

II-C8 Eksport gedcom; tekst/notater?
Forklaring: eksporteres som NOTE til hendelser?, (1 p) Fødsel, (1 p) Konfirmasjon, (1 p) Død, (1 p) Ekteskap, (1 p) Kun rein tekst eksporteres, ingen RTF-koder eller lignende som styrer formatet i tekstfeltet, men som ikke har noe i selve tekstfeltet å gjøre? Program som kan eksportere slike styringsparametre må gi bruker et valg slik at dette kan skrus av. (1 p) Linjeskift CONC/CONT korrekt (fødselsnote person 4 skal ha CONT x2 etter første avsnitt og så en CONC) Vedr. CONC/CONT gjelder følgende:Gedcom tekst-linjer har en begrensning på 255 karakterer. ”CONCatenation” og ”CONTinuation” tags kan bli brukt til å oppheve denne innebygde begrensningen. ”CONT” linje betyr styrt/tvunget linjeskift (som oppstår når vi bruker ”Enter-tasten” på tastaturet). Ved import skal dette synes som en kontrollert brutt linje i mottaende program. Ved eksport skal eksporterende program markere tvunget linjeskift ved å starte neste linje med CONT. ”CONC” betyr sammenhengende tekststreng. Ved import betyr CONC i begynnelsen av en tekstlinje betyr at den tekststreng som legges inn i et tekst/notefelt i mottagende program skal være en sammenslåing av foregående og CONC linjen i gedcomfilen til en sammenhengende tekststreng. Ved eksport betyr det at dersom en tekststreng er på over 255 karakterer så skal linjen kuttes etter 255 karakterer og neste linje begynne med CONC.Eksempel CONC/CONT:”Det er litt uklart når Svein ble født i og med at han var adoptivbarn på øvre Brekke.Her vokste han opp hos sine adoptivforeldre, som ikke hadde andre barn. Svein arvet etter hvert gården etter en tvistesak med adoptivfarens halvbror. Adoptivforeldrene fikk aldri vite hvem som var Sveins biologiske foreldre. Begge adoptivforeldrene døde før 1990.”Dette er en tekststreng som består av 347 karakterer inklusive mellomrom mellom ordene og den inneholder 2 linjeskift (etter punktum i første setning). Etter linjeskiftene er det en sammenhengende tekststreng på 263 karakterer.Korrekt gedcom er her:2 NOTE Det er litt uklart når Svein ble født i og med at han var adoptivbarn på øvre Brekke. 3 CONT3 CONT Her vokste han opp hos sine adoptivforeldre, som ikke hadde andre barn. Svein arvet etter hvert gården etter en tvistesak med adoptivfarens halvbror. Adoptivforeldrene fikk aldri vite hvem som var Sveins biologiske foreldre. Begge adoptivforeldren3 CONC e døde før 1990.Gis brukeren ikke et slikt valg og tekstformateringen eksporteres skal det trekkes 1 poeng.. Dersom et program ikke har mulighet til å ha tekst/noter knyttet til hendelser, men annen relevant metode for å registrere/eksportere dette komplett og korrekt så skal det ikke trekkes poeng her.
Poeng: Ref. over

II-C9 Eksport gedcom; ÆØÅ?
Forklaring: (2 p) ANSEL fil viser INGEN æøå/ÆØÅ karakterer. (2 p) ANSI fil viser ingen ”merkelige” tegn for æøå/ÆØÅ?(1 p) ANSEL/ANSI oppgis korrekt i heading. Program som ikke har mulighet for ANSEL eller ANSI skal ikke trekkes for dette her, det er ivaretatt et annet sted.
Poeng: Ref. over.

II-C10 Eksport gedcom; dato?
Forklaring: Kommer alle dato felt korrekt inn?(1 p)Vanlige datoer (1 FEB 1970)?(1 p) Norske kort-måneder (mai, okt, des) oversatt til MAY, OCT, DEC? (1 p) Datomoderator AFT og BEF? (1 p) Datomoderator ABT? (1 p) Datomoderator BET – AND? (1 Per Roger Oband yrke)Program som for eksempel ikke har mulighet for å legge inn datomoderatorer (før, etter etc) skal ikke trekkes for manglende informasjon i eksportfilen. Det er ivaretatt et annet sted.
Poeng: Ref. over.

II-C11 Eksport eksterne filer?
Forklaring: Programmet eksporterer linker til eksterne filer som en del av eksportrutinen.
Poeng: 5 = OK.

II-C12 Import; slektsdatafiler av andre format enn Gedcom?Forklaring: Programmet kan importere komplette databaser med slektsinformasjon fra andre program uten å bruke gedcom.Poeng: 5= mer enn 6 andre, 1= 1 i tillegg til egne filer
II-C13 Import gedcom; import av kilder?Forklaring: Her testes det på forskjellige dimensjoner ved kildeimport.
Poeng: (1 p) alle variablene i hovedkilden (Forfatter, tittel, utgivelsesår, Kortnavn..), (1 p) import til tilsvarende felt (variabler hovedkilde) i mottagende program, (1 p) kildedetaljene (sidenr. Etc), (1 p) kvalitetsindikator (0-3), (1 p) Kommer mer enn 1 kilde med pr. hendelse

II-C14 Import gedcom; import av navn/personer?
Forklaring: Her testes det på forskjellige dimensjoner ved personimport.
Poeng: (3 p) kom alle personene med, (2 p) kommer mer enn 1 navnevariant med? Dersom ekstranavnet legger seg for eksempel i et notefelt eller et annet ”diversested”, trekkes 1 poeng.

II-C15 Import gedcom; import av hendelser?
Forklaring: Her testes det på forskjellige dimensjoner ved import av hendelser.
Poeng: (1 p) Kom hendelsene fødsel (BIRT), konfirmasjon (CONF), død (DEAT), yrke (OCCU) med?, (1 p) kommer flere hendelser av samme type pr. person med?, (1 p) kommer hendelsene ”EVEN/TYPE” med i et generelt tekstfelt/diversehendelse?, (2 p) Lager mottagende program nye hendelser dedikerte ”EVEN/TYPE” Det er minst 2 typer dåpshendelser med i gedcom. BAPM og CHR. Forskjellen på disse er noe uklar. Hensikten med dette i testen er å finne ut om importerer både CHR og BAPM. Program som legger inn samme hendelse flere ganger enn angitt i gedcom kan trekkes 1 poeng.(Trekk 1 poeng) Dersom ”_BING” importeres uten at du kan stoppe det.

II-C16 Import gedcom; import av relasjoner?
Forklaring: Her testes det på forskjellige dimensjoner ved personrelasjoner.
Poeng: (3 p) kommer hendelsen ekteskap (MARR) med?, (2 p) kommer hendelsen forlovelse (ENGA) med?

II-C17 Import gedcom; import av notater?
Forklaring: Her testes det på forskjellige dimensjoner ved notater og fritekstfelt.
Poeng: kommer alle tekstfelt/notater med på korrekt hendelse? (1 p) Fødsel, (1 p) Dåp, (1 p) Konfirmasjon, (1 p) Død, (1 p) Ekteskap, , (Trekk 1 poeng) Andre notatfelt som ikke blir med, (Trekk 1 poeng) Tekst formatering endres (eks. linjelengder CONC/CONT), ref. II-C8. Program som for eksempel ikke har tekstfelt knyttet til alle hendelser, skal ikke trekkes i poeng dersom all informasjon kommer inn i relevante tekstfelt på personen.
Ref. II-C19.

II-C18 Import gedcom; import av ÆØÅ?
Forklaring: Her testes det på forskjellige dimensjoner ved norske særtegn.
Poeng: kommer all tekst i alle felt over med ÆØÅ? (2 p) Navn?, (1 p) Stedsnavn?, (1 p) Kilder?, (1 p) Notatfelt?

II-C19 Import gedcom; import av dato?
Forklaring: Her testes det på forskjellige dimensjoner ved datoformater.
Poeng: Kommer alle dato felt korrekt inn? (1 p)Vanlige datoer (1 FEB 1970)? (1 Per Roger Oband født og konfirmert) Manglende skuddårsdato skal trekkes med 1 poeng (16 Mari Stua Nevnt 29.2.2000), (1 p) Datomoderator AFT og BEF?, (1 p) Datomoderator ABT?, (1 p) Datomoderator BET – AND?, (1 p) “Ekstraservice:” (2 av 3 for å få 1 poeng) Vanlige datoer ( 1.2.1970)? (Skulle vært ”1 FEB 1970”, men bør tas inn), b) Datomoderator CA/CIR? (ikke gyldig, men bør tas inn korrekt), Datomoderator BETWEEN – AND? (ikke gyldig, men bør tas inn korrekt) Dersom programmet importerer importerer ”1.2.1970” feil (eks. til 2 jan 1970) og dette ikke er varslet i importrutinen skal det trekkes 2 poeng. Dersom programmet importerer ”1.2.1970” uten å oversette dette til internt korrekt format og dette ikke er varslet skal det trekkes 1 poeng.

II-C20 import eksterne filer?
Forklaring: Gedcom åpner for import av multimediaobjekter. Det er kun metoden med linkede objekter som anbefales brukt. Programmet importerer ekstern fil via linker som en del av importrutinen. Programmet bør gi deg følgende valg; a) importer link til mappe på pc’en eller b) kopier link og bilde til et angitt sted på pc’en. Videre bør programmet lete andre steder på pc’en enn der gedcom-filen er lagret.
Poeng: 5 = alle valgene, 4 = 2 av valgene, 3 = 1 av valgene, 2 = ingen valg, import direkte

II-C21 Import gedcom; gir oversikt over endringer/manglende informasjon?
Forklaring: Programmet skal vise hvilke gedcom-detaljer som a) ikke importeres og b) hvilke detaljer som legges et annet sted enn der det hører hjemme iflg gedcom fil.. Ideelt sett bør programmene vise dette før import, i form av et skjermbilde der bruker kan påvirke hvor i mottagende program disse avvikene skal havne og om de ønskes inn i programmet. Dersom importavvikene kun skrives ut i etterkant av importen, skal det tydelig vises på skjermen hvor denne avviksrapporten er lagret.
Poeng: 5= dersom alle endringer vises før import, 3= dersom det kun kommer en komplett liste over endringer etter import (vises på skjermen direkte). 0 = dersom listen ikke er komplett

II-C22 Import gedcom; varsler om imp. skal legges over/flettes eller ny file skal etableres?
Forklaring: Programmet skal hindre at importert gedcom-fil ukontrollert blander seg med de data du allerede har lagt inn. Brukeren skal ha mulighet til å gjøre et bevisst valg om hvorvidt importen skal blandes med eksisterende base eller ikke. Konsekvensen av en slik ukontrollert blanding kan være at du får en mengde uønskede personer og informasjon inn i basen som da kan bli uoversiktlig og rotete..
Poeng: 5=OK

[Otto Jørgensen]

Jeg har i dag mottatt en GEDCOMfil fra Legacy5.0 generert med bakgrunn i data som er lagt inn som testfil i Legacy og her er mye rart når det gjelder bruk av koder båder for vanlige datoer og datospenn.

Det unders meg litt at man ikke tar med hele spekteret av datoformatet i testen, hvilket vil omfatte vanlige enslige datoer og datospenn.

Videre også andre ting knyttet til datoer, bl.a. finnes datokoder som
2 _CDATE 5 Apr 2001
2 DATE Feb 1911-Dec 1915
4 _DATE 9 Oct 1957
2 DATE 1866-1884

[dn10375]

....
II-C10 Eksport gedcom; dato?
Forklaring: Kommer alle dato felt korrekt inn?(1 p)Vanlige datoer (1 FEB 1970)?(1 p) Norske kort-måneder (mai, okt, des) oversatt til MAY, OCT, DEC? (1 p) Datomoderator AFT og BEF? (1 p) Datomoderator ABT? (1 p) Datomoderator BET – AND? (1 Per Roger Oband yrke)Program som for eksempel ikke har mulighet for å legge inn datomoderatorer (før, etter etc) skal ikke trekkes for manglende informasjon i eksportfilen. Det er ivaretatt et annet sted.
Poeng: Ref. over.
.....
II-C19 Import gedcom; import av dato?
Forklaring: Her testes det på forskjellige dimensjoner ved datoformater.
Poeng: Kommer alle dato felt korrekt inn? (1 p)Vanlige datoer (1 FEB 1970)? (1 Per Roger Oband født og konfirmert) Manglende skuddårsdato skal trekkes med 1 poeng (16 Mari Stua Nevnt 29.2.2000), (1 p) Datomoderator AFT og BEF?, (1 p) Datomoderator ABT?, (1 p) Datomoderator BET – AND?, (1 p) “Ekstraservice:” (2 av 3 for å få 1 poeng) Vanlige datoer ( 1.2.1970)? (Skulle vært ”1 FEB 1970”, men bør tas inn), b) Datomoderator CA/CIR? (ikke gyldig, men bør tas inn korrekt), Datomoderator BETWEEN – AND? (ikke gyldig, men bør tas inn korrekt) Dersom programmet importerer importerer ”1.2.1970” feil (eks. til 2 jan 1970) og dette ikke er varslet i importrutinen skal det trekkes 2 poeng. Dersom programmet importerer ”1.2.1970” uten å oversette dette til internt korrekt format og dette ikke er varslet skal det trekkes 1 poeng.

På no.fritid.slektsforsking.it har det gått en laang tråd i det siste om datoer i GEDCOMfiler, du kan lese denne via herværende Slektsforum.
Her er noen kommentarer til DIStesten:

Ole Bjørn Darrud skriver i tråden ovenfor:
....
>
>DIS-Norges test slik den i dag fremstår fanger ikke opp alle de
>problemstillinger som er tatt opp her ang. gedcom og bruk av parentes.
>De nye testkriteriene som det nå jobbes med vil fange opp både import og
>eksport av tekst i datofelt.
>"Alle" program vil i denne sammenheng bli testet opp mot de nye kriteriene.
....
Etter mitt syn bør DIS-Norges tester(e) bruke sin prisverdige og tilmålte fritid til tester som er skikkelig viktige, denne parentesen er bare en parentes i denne sammenheng, den er ytterst lite interessant og helt uten betydning for slektsforskere. Og det er jo ingen som vil ha en parentes rundt datoer i sine utskrifter.
Om den kreves i den gamle, stivbeinte og utdaterte GEDCOMstandarden er uviktig, og diskutabelt. DIS-Norges DIStreffprogram har heller ingen relevans her, om dette har lyst på parenteser.

Det som er viktig å teste for innlegging og GEDCOMeksport av datoer i et slektsdataprogram er at programmets inntastingsskjermbilde

a) sier fra på en tydelig måte til brukeren om den inntastede dato _ikke_ er akseptert som en gyldig dato

b) om aksepterte datoer eksporteres på korrekt format til GEDCOMfil, altså DD MMM ÅÅÅÅ med engelsk MMM

c) at irregulære datoer (feks rein tekst) i datofeltet er mulig, men at programmet sier fra om dette til brukeren når slik registrering skjer

d) eksporten av irregulære "tesktdatoer" skal skje uten endring av teksten

e) i tillegg må det, som nå, testes om de vanlige datomodifikatorer kan legges inn og blir akseptert som en gyldig dato og blir eksportert med de korrekte modifikatorkoder


På importsida for datoer er det sjølsagt ønskelig at programmet er mest mulig alt-etende uten dikkedarer. Hvis programmet forstår og aksepterer en dato er det ingen vits i å plage brukeren med meldinger om at leveransen fra det andre programmet var kritikkverdig. Men hvis datoen er av typen fritekst eller irregulær, bør dette meldes fra om i den tilhørende kvitteringsfil fra importprosessen.

Lykke til videre med den verdifulle oppdateringa av testen!

[Ole Bjørn Darrud]

Torleif

mye av det du påpeker tester vi på.

Det som er litt merkelig er at du hevder at DIS-Norge skal se bort fra gedcom-standarden når det passer deg.
Kan det være fordi TMG ikke følger standarden her?
Anbefaler at du bruker kreftene på å få Bob V til å fikse en eventuell feil fremfor å engasjere deg på denne måten.

Mvh
Ole Bjørn

[Otto Jørgensen]

Det er i testing av GEDCOM helt viktig å skille på importen og eksporten.

Ved eksport må det være en forutsetning at data er lagt inn slik programmet forutsetter det skal gjøres og ikke etter hva brukeren tror/forutsetter/ønsker.
At en bruker vil legge inn data på en annen måte MÅ være en annen test og ikke en test om hvordan et program handterer GEDCOMstandarden.

Ved import er det også GEDCOMstandarden som legges til grunn og ikke andre ting.
Det som her kan diskuteres er hvordan et program skal handtere avvik.
Skal avviket avvises, eller skal det importeres.
I hvor stor grad skal det igjen gis varsel om at det er foretatt en import av et datoformat utenfor standard.
Et eksempel fra testen er en import av en GEDCOMfile hvor formatet "29.2.2000 eller (29.2.2000)" er med i GEDCOMfilen. ?

[dn10375]

Torleif

mye av det du påpeker tester vi på.

Det som er litt merkelig er at du hevder at DIS-Norge skal se bort fra gedcom-standarden når det passer deg.
Kan det være fordi TMG ikke følger standarden her?
Anbefaler at du bruker kreftene på å få Bob V til å fikse en eventuell feil fremfor å engasjere deg på denne måten.

Mvh
Ole Bjørn

Jeg kjenner ingen program som bruker denne parentesen, den er helt unødvendig. Husk at GEDCOMstandarden er 10 år gammel, det har skjedd utrolig mye med slektsprogrammene siden dengang da.

Kan du ikke heller kommentere de konkrete forslagene?
Øvrige overraskende kommentarer står for din regning.

[Ole Bjørn Darrud]

Torleif
DIS-N testen er som kjent basert på gedcom 5.5.
Det blir useriøst på subjektivt grunnlag å se bort fra denne standarden når det passer slik.
Troverdigheten i slike innlegg faller tilsvarende.
Hvorfor ikke be Bob V fixe en evt. feil?

[Otto Jørgensen]

Jeg har som mange vet vært uenige i en del av de tidligere resultatene, men når vi først er i diskusjonen om dato-formater, så er det etter min mening ikke mer enn rimelig at dette nå testes fullt ut for samtlige programmer og at man ikke kun tar tak i en liten del.
Derfor bør DIS-testen utvides til å fange opp dette med datoformater på en bedre måte.

Dette for å får frem faktiske forhold en gang for alltid. Så får vi "program-fans" jobbe mot respektive produsenter.

I tillegg kan også dette bidra til at DISTREFF ser status rundt omkring og ikke lager så mye støy når bidragene inneholder for "mye feil"

Jeg forutsetter selvfølgelig at all testing går ut på siste versjoner av respektive program. I tillegg må DIStreff bidra med å dempe støyen ved å henvise innsender av bidrag til Distreff til å oppdatere sine programmer hvis det her finnes utbedrede utgaver som også i større grad tilfredstiller DISTREFF innenform den GEDCOM-standard som i grunnen her er lagt som en basis.

Hva program gir av kvalitet på dette området vil da stå i testen og ikke bli gjenstand for gjentagene diskusjoner i mange ulike fora.

[Ole Bjørn Darrud]

Hei

her er nytt importkriterium knyttet til dato:

II-C19 Import gedcom; import av dato?
Forklaring: Her testes det på forskjellige dimensjoner ved datoformater.
Poeng: Kommer alle dato felt korrekt inn?
(1 p)Vanlige datoer ”1 FEB 1970”? (1 Per Roger Oband født og konfirmert) Manglende skuddårsdato skal trekkes med 1 poeng (16 Mari Stua Nevnt 29.2.2000),
(1 p) Datomoderator AFT og BEF?,
(1 p) Datomoderator ABT?,
(1 p) Datomoderator BET – AND?,
(1 p) Tekst i datofelt. (1. påskedag) [dåp Guri Malla] skal importeres som tekst.
Tekst som ikke er omsluttet av parentes eller datoformat som ikke følger standard (ex. 1 MAR 1970) skal kunne importeres, men importrutinen skal varsle før import/i importlog om slike feil. Program som ikke varsler om slike feil skal trekkes 1 poeng.

Her kan det altså trekkes inntil 2 poeng for importfeil knyttet til tekst/feil datoformat.


Hovedpunktet er som mange har påpekt å hindre uønsket informasjon i datofeltet. Dette er det allerede et eget 5-poengs punkt for.
Teksten her er gjort tydeligere:

I-C2 Datoformat sjekkes ved innlegging i felt mot innebygd standard?
Forklaring: Programmet skal varsle når dato legges inn på en ulogisk måte i forhold til valgt datoformat. Det skal mao varsles tydelig når dato ikke kan oversettes til Gedcom eller en standard som ligger inne/bruker selv kan velge. Dette gjelder f.eks datoen ”1. pinsedag” hvor programmet spør om denne ”ugyldige” datoen skal gjelde og sier fra (minimum i brukerveiledningen) hva konsekvensen for gedcom da er.
Poeng: 5= varsel/dialogboks



Mvh
Ole Bjørn

[6878]

Hei,

Hvilket punkt er det som tester om ( ) er med ved eksport?

Det er vel viktigere enn å varsle ved import.

Geir

[Ole Bjørn Darrud]

Geir

dette punktet er også noe justert.

II-C10 Eksport gedcom; dato?
Forklaring: Kommer alle dato felt korrekt inn?
(1 p)Vanlige datoer (1 FEB 1970)?
(1 p) Norske kort-måneder (mai, okt, des) oversatt til MAY, OCT, DEC?
(1 p) Datomoderator ABT, AFT og BEF?
(1 p) Datomoderator BET – AND? (1 Per Roger Oband yrke)
(1 p) Tekst i datofelt? Tekst eller tidsinformasjon som ikke kan oversettes til standard gedcom format skal omsluttes av parentes.Program som for eksempel ikke har mulighet for å legge inn datomoderatorer (før, etter etc) skal ikke trekkes for manglende informasjon i eksportfilen. Det er ivaretatt et annet sted.
Poeng: Ref. over.

[dn10375]

II-C10 Eksport gedcom; dato?
Forklaring: Kommer alle dato felt korrekt inn?
....
(1 p) Tekst i datofelt? Tekst eller tidsinformasjon som ikke kan oversettes til standard gedcom format skal omsluttes av parentes.

Er det parentesene eller brukerens faktiske inntastede data i datofeltet som er viktig her?
Skal du trekke et poeng hvis brukerens data overføres uten endringer, men mangler disse unødvendige parentesene?
Testens tittel er "Tekst i datofelt" og bør gjelde akkurat det, om teksten eksporteres som den er.

"..alle dato felt korrekt inn", hva menes med det?

[Ole Bjørn Darrud]

Torleif

informasjon i dato felt som ikke er gyldige datoer skal omsluttes av parentes. Dette skal programmet legge til ved eksport og ta bort ved import.

Ole Bjørn

[dn10375]

Torleif
informasjon i dato felt som ikke er gyldige datoer skal omsluttes av parentes. Dette skal programmet legge til ved eksport og ta bort ved import.
Ole Bjørn

Så testen er en parentestest, og ikke en datatransporttest, da må spørsmålet endres tilsvarende.
Jeg stilte et partre spørsmål i denne anledning, hva blir svaret på dem?

[Ole Bjørn Darrud]

Dette ene lille punktet er en test på hvordan programmet håndterer import og eksport av informasjon i dato felt som ikke er gjenkjent som dato, kalt "tekst" her.
Testen vil også omhandle hvordan slik informasjon bør behandles når den mangler parentesen.
Her ser jeg for meg at programmet bør varsle ved import at det ligger informasjon i datofeltet som ikke er korrekt. Programmet bør kunne importere dette "as is" etter at dette tydelig er varslet.
Et riktig godt program bør vel kanskje varsle tilsvarende om det ligger parentesomsluttet info her.

Ole Bjørn

[6878]

Jeg har et spørsmål litt på siden av debatten.

Hvis et program kan registrere både fritekst (julaften 1234) og vanlig dato (24.12.1234). Hvordan skal dette eksporteres i Gedcom?

Er
2 DATE INT 24.12.1234 (julaften 1234)
eneste mulighet?
INT står for INTerpreted - dvs den vanlige datoen er avledet av fritekst varianten.

Eller finnes andre muligheter der den ene ikke trenger å være avledet - dvs f.eks at presten har skrevet datoen i begge varianter - noe som forekommer.

Geir

[Otto Jørgensen]

Men kan en ikke skrive inn datoen 24.12.1234 i datofeltet og så legge inn "juleaften 1234" i merknadsfeltet til hendelsen. Det kan jo være at man også vil legge inn andre opplysninger til den dagen, f.eks. at det var det "værste uværet i manns minne"

Dermed har en i grunnen løst alle behov.

[6878]

Men kan en ikke skrive inn datoen 24.12.1234 i datofeltet og så legge inn "juleaften 1234" i merknadsfeltet til hendelsen. Det kan jo være at man også vil legge inn andre opplysninger til den dagen, f.eks. at det var det "værste uværet i manns minne"

Dermed har en i grunnen løst alle behov.

Jeg skal ikke nekte noen å gjøre det, men det var ikke det spørsmålet gjaldt. Noen foretrekker mora og noen dattera. Jeg synes ikke det du beskriver er den best mulige løsningen.

Det kan dog hende at en tilleggsmerknad blir løsningen i de meget få tilfellene at vanlig dato er ført i tillegg til kirkedagen (friteksten) hvis Gedcom kun har INT muligheten - merknaden vil si at selv om INT er brukt så er vanlig dato ikke bare en fortolkning av friteksten.

Geir

[Otto Jørgensen]

Man kan jo diskutere hva som er enklest. Skriver man inn i teksten den teksten som står i kirkeboken så har man også lagt inn denne opplysningen, Man kan gjerne også skrive det inn som kommentar i selve kilden.

Det vil da, ut fra hvordan den enkelte former teksten, klart kunne si at dette er beregnet dato ut fra et eller annet datotabell/program.

Jeg vil ikke tro at verdien av informasjonen av den grunn blir dårligere, kun gjort på en annen måte.

[dn10375]

Man kan jo diskutere hva som er enklest. Skriver man inn i teksten den teksten som står i kirkeboken så har man også lagt inn denne opplysningen, Man kan gjerne også skrive det inn som kommentar i selve kilden.

Det vil da, ut fra hvordan den enkelte former teksten, klart kunne si at dette er beregnet dato ut fra et eller annet datotabell/program.

Jeg vil ikke tro at verdien av informasjonen av den grunn blir dårligere, kun gjort på en annen måte.

Otto har helt rett. Brukeren bør registrere en dato som programmet tolker som er dato, evt. med modifikatorer som før/etter eller fra-til, og så bør den eksakte dato/tidsangivelsen som står i kilden skrives i en fritekstboks for kildereferansen. I tillegg kan det evt. gis en kvalitetskode for datoen som sådan om det er relevant.
På denne måten er programmet etterpå i stand til å sette hendelsen i riktig rekkefølge ifht de andre, og den kan brukes til sortering på datoer osvosv.

[6878]

Jeg ser ingen grunn til ikke å premiere håndtering av INT og innskriving av begge datoformater i datofelt, så lenge det finnes program som håndterer dette.

Det gir så vidt jeg kan forstå en bedre formatering i rapporter (uten å måtte ty til evt. triks) og en enklere innlegging av datoen.

Det finnes program som håndterer både kvalitetskode og sortering selv om man supporter INT og innskriving av begge formater i datofelt.

Geir