Ik zie de laatste tijd weer meer items van GenealogieOnline (GO) gebruikers die zich zorgen maken maken over de volgende melding op de Publicatiebeheer pagina van hun GO publicatie:
"Controle van uw ... GEDCOM leert dat, er kans op informatieverlies is!".
Doorklikken levert op: Waarschuwing omtrent mogelijk informatieverlies » Genealogie Online (voor de link wel eerst inloggen als beheerder).
Dat heeft er misschien mee te maken dat steeds meer stamboomprogramma's bezig zijn om GEDCOM 7.0 te faciliteren.
Ook wordt er door GO naar iedere gebruiker een periodieke waarschuwingsmail gestuurd met, met "Waarschuwing voor mogelijk gegevensverlies".
Om maar met het slechte nieuws te beginnen: Het is een illusie om te denken dat u bovengenoemde melding of e-mail kunt voorkomen, die zijn er altijd.
Het goede nieuws: De soep wordt nooit zo heet gegeten als ze wordt opgediend.
Na het uploaden door GO word de Gedcom eerst gecontroleerd m.b.v. GED-inline validator software. Ik heb gemerkt dat dat soms al gebeurt terwijl de job nog in de wachtrij staat om verder door GOnline verwerkt te worden.
GED-inline is een standard GEDCOM validator die niet geschreven is door GO. Daarmee bedoel ik te zeggen dat GED-inline op geen enkele manier rekening houd met de GO context. GED-inline kijkt alleen naar wat er in de betreffende GEDCOM specificatie staat. Omgekeerd heeft GO geen enkele invloed op welke tests wel en niet uitgevoerd worden.
Er zijn meer van dat soort validator programma's, zoals b.v. de Chronoplex GEDCOM Validator, die je gratis op je eigen computer kunt installeren. Die heeft voor GEDCOM 5.5.1 zelfs een keuze uit "Best practice" en "Standards Only".
De GED-inline software maakt een rapport. In de Header van dat rapport staan o.a. het aantal gevonden fouten en/of waarschuwingen. Die Header wordt door GO getoond op de Waarschuwing omtrent ... pagina. Onderaan die pagina een knop waarmee het volledige rapport door de GO gebruiker gedownload kan worden.
Als het aantal fouten plus het aantal waarschuwingen nul is toont GO waarschijnlijk een andere tekst dan de bovengenoemde. Welke tekst dat is weet ik niet, want ik heb nog nooit een rapport met nul fouten/waarschuwingen gezien. Zelf zou ik in dat geval ook niet durven beweren dat er geen informatie verlies is, want GEDCOM heeft zo zijn beperkingen.
Dit geeft al aan dat we waarschijnlijk e.e.a. wat moeten nuanceren.
=== EDIT: Ondertussen toch een gedcom geüpload met 0 fouten, hoera.
Lines 198817 Number of lines in the GEDCOM file
Records 9465 Number of records
Warnings 0 Total number of warning messages
User-defined 41 Number of lines with user-defined tags
GO blijft echter hardnekkig waarschuwen voor gegevensverlies, in plaats van een bosje bloemen te bezorgen. GO valt blijkbaar ook over het gebruik van 41 User-defined tags. GEDCOM 7.0 heeft inderdaad de (onrealistische) eist van een schema definitie voor iedere user-defined tag.
== einde EDIT.
Vooral van belang is hoe GO omgaat met eventuele tekortkomingen van de aangeleverde Gedcom. Mijn ervaring is dat Bob Coret wat dat betreft pragmatisch is en altijd probeert de bedoeling van het gebruikte stamboomprogramma te achterhalen.
Twee voorbeelden van een GED-inline waarschuwing in een 5.5.1 Gedcom:
*** Line 81: Invalid content for FILE tag: the value is more than 30 characters, the maximum length for
*** Line 755: Invalid content for ROLE tag: '(overleden partner)' is more than 15 characters, the maximum length for
Op regel 81 staat een pad naar een bestand met een totale lengte meer dan 30 karakters. Dat is een beperking waarvan we allemaal weten dat het echt onvoldoende is, daar dachten ze in de vorige eeuw bij het opstellen van de 5.5.1. spec. anders over. GO heeft geen enkele moeite met langere padnamen.
Dat die ROLE op regel 755 maar maximaal 15 karakters lang mag zijn is een rekenfoutje dat gemaakt is door de opstellers van de 5.5.1 spec, zie blz 61 van die spec. Er had minstens 25 moeten staan, maar ja, in de spec staat 15, dus moet GED-inline er iets van zeggen.
GO accepteert echter een ROLE die veel langer is en verwerkt die helemaal correct.
Het gaat hier om waarschuwingen, d.w.z. dat de beperkende regeltjes aanbeveling zijn. Het gaat dus niet om een echte fout.
Eén van de moderniseringen in GEDCOM 7.0 is dat veel van deze lengte beperkingen verdwenen zijn. Zelfs de CONC tag is afgeschaft omdat men er van uitgaat dat een tekst altijd op één regel past.
Nog een padnaam waarschuwing, ditmaal GEDCOM 7.0:
*** Line 200314: Invalid content for FILE tag: 'Scholl/internet/18130208_DukenbergJ+B_Epe_ BSgebA11_FAim84.jpg' is not a valid
Er staat een spatie in deze bestandsnaam, iets dat in GEDCOM 7.0 kennelijk afgeraden wordt. In eerdere GEDCOM versies stond daarover niets en werd er dus ook niet op getest.
Vanwege dat laatste, moet GO in staat zijn om te gaan met spaties in pad en bestandsnamen ten behoeve van die eerdere GEDCOM versies.
Ik kan u verzekeren dat Bob Coret nu voor GEDCOM 7.0 een pad of bestandsnaam met een spatie er in niet gaat weigeren. Ik probeer spaties in bestandnamen altijd te vermijden, want vroeg of laat geeft dat toch vaak problemen. Dus heb ik de 2 gevallen waar ik dat over het hoofd gezien had gecorrigeerd. Als dit in uw stamboom dossier bij heel veel bestandsnamen voorkomt, is het haast niet te doen dit allemaal te corrigeren. Maakt u zich dan geen zorgen, want GO kan er prima mee omgaan. Wel vervelend van die vele GED-inline meldingen hierdoor.
Daar is misschien ook nog iets tegen te doen.
Bij een publicatie op GO zou u zich af kunnen vragen of u alle dossier bestanden ook wilt uploaden. Persoonlijk deed ik dat nooit, maar sinds kort, alleen wat pasfoto's. In mijn stamboomprogramma GensDataPro kan ik bij het aanmaken van een Gedcom bestand kiezen uit de opties "Dossiers weglaten", "Dossiers opnemen" of "Alleen pasfoto's opnemen", waar ik dus voor het laatste kies. Als er spaties voorkomen in mijn pasfoto bestandsnamen zou ik die wel corrigeren, omdat het er niet zo veel zijn. De andere bestandsnamen uit mijn dossier komen niet in het Gedcom bestand voor en kunnen dus ook niet meer de bovengenoemde waarschuwingen veroorzaken.
Als u in uw stamboomprogramma ook een dergelijke keuze hebt en niet van plan bent dossier bestanden te uploaden, kies dan voor "Dossiers weglaten". In dat geval verdwijnen dus alle bovengenoemde waarschuwingen in het GED-inline rapport.
Er is ook een categorie mogelijke meldingen in het GED-inline rapport waar u niets aan kunt doen als gebruiker. Die moeten opgelost worden door de makers van het door u gebruikte stamboomprogramma.
TOEVOEGING 31-12-2024:
warnings: Invalid content for FORM tag: 'jpg' is not a valid
Invalid content for FORM tag: 'JPG' is not a valid
Ik denk dat .jpg of .JPG niet uitmaakt, voor beiden geldt dat de FORM value in GEDCOM 7.0 niet hetzelfde is als voor 5.5.1. Dit valt overigens in de categorie die door stamboomprogramma beheerders opgelost moet worden.
Voor 7.0 is het een MediaType: "/" , zie GEDCOM 7.0 blz 30.
Wat je ook meer ziet in de 7.0 spec is dat niet alles vastgelegd wordt in de GEDCOM spec zelf, maar dat er doorverwezen wordt naar een andere standaard, in dit geval RFC 2045, zie Media Types.
Voor .jpg en .JPG bestanden is het Mediatype: image/jpeg, zie kolom "Template". Verder vind je daar ook "image/png", "application/pdf", "application/msword", "text/plain", etc.
dus: x FORM image/jpeg [die e is belangrijk]
==
Als u nog meldingen tegenkomt die het vermelden waard zijn hier, laat het dan weten. Ik zou die dan toe kunnen voegen aan dit openingsbericht voor dit item. In een vervolgbericht zal ik dan melden dat dit bericht aangepast is. Op die manier krijgen we misschien een inventarisatie van mogelijke meldingen, waar naar toe verwezen kan worden.