Problem med GEDCOM 5 import i Disgen

[tommypeters]

Det finns såvitt jag vet bara en enda officiell 5.5-standard, men vad gäller avvikelser, ofullständigheter och tillägg i Disgen får man läsa källkoden. Mängden implementerade privata taggar är i alla fall liten (8 tror jag) och används inte; de är avstängda i de versioner av Disgen som gått ut till allmänheten. Annars finns det t ex en tagg för faddrar. Det är nog ganska otestad mark. Sedan finns det åtskilliga taggar i gedcom som inte stöds i Disgen (tänk på allt det här 'temple ready'-stoffet).

En konfigurationsfil låter bra men jag tror det är tekniskt svårt att "beskriva" avvikelser från gedcomstandarden i en konfigfil. Jag har aldrig kommit till skott, men hade jag gjort den här hanteringen i Disgen hade jag försökt definiera enskilda avvikelser eller tillägg först, på papper, och sedan gjort en lista över alla som ska stödjas. Sedan hade jag skrivit importkod i Disgen och låtit varje "väldefinierad avvikelse" eller tillägg ha sin kodsekvens. Själva användargränssnittet skulle sedan ha varit listor med kryssrutor där användaren väljer vilket program man vill importera från, vilket Disgen skulle mappa på en eller flera "väldefinierade avvikelser", eller så skulle man (avacerat) kunna välja ut enskilda avvikelser direkt.

Vi skulle ju kunna försöka använda wikin för att lista avvikelser eller tillägg och definiera hur de ska hanteras i Disgen och se hur långt vi kommer?

Jovistt finns det bara en oficiell GEDCOM-standard, därför skrev jag det inom citationstecken. En del program kan exportera till ett par-tre 5.5-varianter, i huvudsak tillägg för att få med media som foton och stories - alltså länkar till externt material. I mitt träd har jag t.ex 6855 foton (porträtt, AD-källor, vapensköldar, platsbilder från internet) och 1319 stories, det är inget jag vare sig vill vara utan eller länka till manuellt.

Jag tänkte mig att körningen av "masseraren" skulle vara extremt enkel - rentavt simpel - för användaren. Kanske inte ens ett GUI, på sin höjd in- och utfilsnamn anges.

Tanken är helt enkelt såhär:
Man går igenom filen som ska masseras och när man hittar något som inte DiSGEN kommer att känna igen kollar man om man kan identifiera vad taggen + datat är för något. Antingen hårdkodat i programmet eller via en mönsterbeskrivning i en konfigurationsfil (jag har inte tänkt att användaren själv ska behöva ändra i konfigurationsfilen, det skulle föreningen göra och skicka uppdateringar som ett alternativ till programuppdateringar). Känner man igen taggen (t.ex _PHOTO) så översätter man den till "DiSGEN utökat format" och fortsätter sedan i filen tills nästa mysko tag hittas. Man tar varje okänd tag för sig, bryr sig inte om från vilket program det kommer, man vill inte komma in i någon modal körning i programmet.

[Christer]

Hittade idag ett verktyg för validering av GEDCOM-filer om någon är tänd på att testa. Se http://chronoplexsoftware.com/gedcomvalidator/index.htm

[DanielBerglund]

Man tar varje okänd tag för sig, bryr sig inte om från vilket program det kommer, man vill inte komma in i någon modal körning i programmet.

Jag tror man måste ta hänsyn till vilket program det är i en hel del fall, t ex om ett visst program genererar i och för sig väldefinierad gedcom men på ett sådant sätt att den inte följer standard. Bara för att hitta på ett exempel: anta att programmet X har växlat betydelsen av IMMI och EMIG men gör i övrigt helt rätt. I ett sådant fall kan inte en masserare veta att IMMI och EMIG ska växlas tillbaka om den inte också vet att filen kommer från just programmet X.

Ett annat fall där jag kan tänka mig att det behövs ett enkelt GUI är där användaren måste ges möjlighet att välja hur konverteringen ska ske. T ex har MinSläkt s.k. konfidentiella noteringar som kan exporteras med den privata taggen _CONF_NOTE. Disgen, däremot, har inte något officiellt begrepp som innebär att en notis är konfidentiell. Tydligen var notistypen "extra text" tänkt så från början men det har inte upprätthållits i praktiken. Här bör man alltså låta användaren av masseraren välja vad som ska ske, dvs välja på några rimliga lösningar som masseraren implementerar.

En sak till som vore bra är om man kan ändra egendefinierade notistyper under konverteringen. Man kanske inte vill använda de som finns i den inkommande gedcomfilen utan vill byta ut dem mot andra.

Nåja, sådana här saker måste inte vara med från början. Det är nog bättre att börja så enkelt som möjligt och se hur långt det räcker i praktiken. Med lite tur räcker det långt nog..

[tommypeters]

OK, jag tänkte inte på att programmen skulle vara så klantiga som ditt exempel med IMMI/EMIG. Precis när vi fixat det i programmet så rättar de det...
Jag tänkte mer på att ta hand om tillägg som var icke-standard, då hade väl mitt tänk fungerat.

Som jag skrev är ju tid en bristvara, så jag tänkte göra det så enkelt som möjligt så att en första version skulle bli färdig någon gång. Samt om man inte skulle hinna slutföra det så skulle det vara enklare för någon annan att fortsätta eller vi skulle fortsätta parallellt med varsin del.

[DanielBerglund]

Håller med om att det är bättre att börja enkelt och bygga om och till med tiden, än att vara överambitiös från början och inte komma i något mål alls.

[DanielBerglund]

Här är en närliggande tanke. Jag tittade just på en gedcomfil som kommer från Legacy 7.5. Den passar Disgen mycket bättre om man kör den genom följande gawkskript:

/^1 _UID/ { next; }
/^2 GIVN/ { next; }
/^2 SURN/ { next; }
/^3 PAGE/ { x = $0; next; }
/^4 CONC/ { if (x != "") { printf("%s%s\n", x, substr($0, 8)); x = ""; next; }}

{ if (x != "") { printf("%s\n", x); x = ""; } 
  print $0; 
}

Nu kan man ju inte be folk köra gawk, men vi skulle kunna försöka bygga upp en samling kodsnuttar i något annat passande språk (php) och lägga upp dem på webben med ett enkelt gränssnitt där man i princip bara tankar upp sin fil och får tillbaka den masserade filen. Alltså, istället för att göra ett (iofs enkelt) program gör man ett antal programfragment och gör dem körbara från ett gemensamt "skal" på webben.

[tommypeters]

Jo, det är ju en möjlighet. Men innan jag börjar med något sådant skulle jag vilja veta om DiSGEN överhuvud taget kan ta in den informationen som finns i min GEDCOM-fil, om den blir "masserad", eller om programmet t.ex. inte har någon möjlighet att importera foton ens om man ser till att inga sökvägar för filer finns i GEDCOM-filen etc.
Och dokumentationen över detta är alltså källkoden...?

[DanielBerglund]

Ja, det finns i alla fall ingen annat skrivet. Sedan går ju trial-and-error i Disgen men det bästa är att försöka kontrollera vad som faktiskt händer bakom kulisserna.

Jag ser (i källkoden) att man hanterar multimediarecords (OBJE), tydligen genom att ta första bilden (definierad som att FORM är någon känd bildtyp, t ex jpg) och sätta den som porträtt och övriga bilder som vanliga bilder. Sedan får man själv kopiera filen till DgPic. Filnamnet förutsätts tydligen vara utan sökväg. Så det finns förutsättningar...