Bob schrijft dat computers user-defined tags niet kunnen lezen. Maar mensen die websites maken kunnen dat wel. Gedcom omzetten naar de website is altijd ook een menselijke activiteit. Dat blijkt alleen al uit het feit dat gegevens die volgens het juiste gedcom-format (geen udt) zijn aangeleverd niet altijd goed overkomen .... 

In de gedcom van GDP bestaat de udt _WITN met als volgende item REFN (2 _WITN naam, 3 REFN @Ix@). Ik zie dat de naam van de getuige bij de gebeurtenis wordt vermeld als tekst, en dat bij de getuige niet vermeld wordt dat deze getuige is van de gebeurtenis.
Wijziging in _WITN @Ix@ levert wel een klikbare getuige op en vermelding van de gebeurtenis bij de getuige.
Navraag leert dat andere programma's nu juist weer wel de door GDP geleverde vorm vragen. 

MIjn vraag is dan ook om rekening te houden met REFN en de udt op de bedoelde (gepubliceerde) wijze om te zetten naar de website. (In de door mij laatst aangeleverde gedcom heb ik alle _WITN .. REFN @IX@ vervangen door _WITN @Ix@ maar dat zou toch niet nodig moeten zijn).

Citaat: Dat blijkt alleen al uit het feit dat gegevens die volgens het juiste gedcom-format (geen udt) zijn aangeleverd niet altijd goed overkomen. 

Niet altijd = De ene keer wel en de andere keer niet; een computer kiest daar niet voor en doet een bepaalde structuur wel of niet; maar degene die probeert een passende mouw te maken heeft zoveel verschillende invals hoeken, dat er soms ook wel eens niet goed gaat.

Komt nog bij dat de header info ook niet altijd juist is met de inhoudelijke Gedcom tag specificatie, genoemd in de header.

Er waren de laatste tijd behoorlijk veel uitdagingen om het de gebruikers naar hun zin te maken; iets wat eigenlijk bedoeld is in een geautomatiseerd proces.

Ik verwacht niet dat Bob elke Gedcom napluist of het wel goed zal gaan.

Kwam nog bij dat meldingen daarin ook niet vlekkeloos verliepen.

Maar mijn laatste Gedcom (28-02) verliep prima; ook wat betreft de meldingen.

Maar ik heb dan ook gezorgd dat daarin alles klopte, zoals Header, versie, Codepage, tags. en onderlinge verband daarmee.

Een zeer tijdrovende bezigheid; zeker als daaruit ook nog functionaliteit moet komen.

De bedoeling in dit soort processen is, dat een Gedcom klopt (dus voldoet aan de specificatie, gemeld in de header) geautomatiseerd wordt doorgevoerd.

Als Bob elke keer correcties moet gaan doen op toevoegingen is het eind zoek.

Te gemoed komen aan udt's is een service die eigenlijk niet te doen is en vaak moet ingrijpen op een werkend systeem.

@Herman: Het is me niet duidelijk in welke rol je deze opmerkingen maakt. Het lijkt me niet je taak om te vertellen dat Bob niet in kan/mag gaan op een vraag. Of ben je (mede)beheerder van de site?

Niet altijd: Bob heeft twee maal toegegeven dat correcte gedcom niet juist werd verwerkt: het ene is hersteld, het andere is in onderzoek. Het geeft aan dat het omzetten van gedcom naar data mensenwerk is, natuurlijk geautomatiseerd, maar eerst geprogrammeerd. Hetzelfde geldt voor omzetten van data naar gedcom. Mijn vraag is nu of een op zich toegestane udt in de programmering kan worden meegenomen. Ik zie niet in dat er iets mis is met die vraag.

Je suggereert dat de aangeleverde gedcom niet klopt zonder enige kennis van de aangeleverde gedcom. Ik vind dat hoogst aanmatigend en blijf daarvan liever verschoond. 

Dat laatste heb ik niet gezegd, maar is wel ervaring, dat het vaak voorkomt. Dan ook nog handmatig aanpassen, zonder een fout ergens achter te laten ?

Verder speel ik geen enkele rol; behalve dat ik reageer als er te gemakkelijk wordt geroepen. Geen reacties willen doe het via de private mail en niet openbaar, waar reageren vrij staat.

We zijn allemaal gebaat bij een standaardisatie met of zonder gebreken, daar kun je wat mee.

Het omgekeerde is gewoon fout !

En een stukje code zegt niets over de afwerking van je Gedcom, in welke software dan ook.

Het gaat om het totale plaatje en dan ook nog udt's.

99% van de software voldoet er niet aan en sommige ook nog dramatisch verouderd.

Citaat: MIjn vraag is dan ook om rekening te houden met REFN en de udt op de bedoelde (gepubliceerde) wijze om te zetten naar de website

Dat blijft dweilen met de kraan open; ik ben er meer voor om de standaard te handhaven.

Er is meer mogelijk dan menig geen denkt, dan udt's gebruiken.

Softwaremakers, zorg dat je Gedcom op orde is binnen de standaard en volgens de header die je als info mee stuurt in de eigen Gedcom.

Ik heb de afgelopen weken al genoeg hiaten zien passeren.

@Tobias,

Ik heb Genealogie Online zo gemaakt dat een bepaalde set van GEDCOM tags begrepen worden. Dit is allereerst de set tags die in de GEDCOM specificatie zijn beschreven. Als alle ontwikkelaars, die GEDCOM maken en die GEDCOM lezen, deze afspraken goed opnemen in hun code is de kans op gegevensverlies minimaal.

Bij de user-defined tags heb je te maken met door een enkele ontwikkelaar (of team) bedachte tag. Wat deze inhoud en hoe deze behandeld moet worden is dan vaak de eerste hobbel. Dan is het nog zo dat "alle andere" stamboomprogramma's en -diensten deze nieuwe tag moeten coderen in hun programma, dit laatste gebeurd vaak maar mondjesmaat. Het is helaas ook nog niet zo dat de bedenkers van de udt's deze promoten bij andere ontwikkelaars, dat ze er draagvlak voor zoeken.

Voor Genealogie Online bekijk ik per tag, en dan is vooral van belang of deze goed is gedocumenteerd, of deze tag echt iets toevoegt of dat dit ook met standaard GEDCOM kan en of deze veel voorkomt in de GEDCOM's op Genealogie Online. Zo doende heeft Genealogie Online als diverse uitzonderingen, ik bedoel udt's, gecodeerd van diverse stamboomprogramma's.

Op dit moment "snapt" Genealogie Online de "_WITN" tag al (ook PROGEN gebruikt deze tag), maar nog niet dat daaronder een REFN kan komen met een @id@ (en dus ook niet hoe dit dan weergegeven moet worden). Ik zet 'm op mijn TODO lijst.

Prima, ik wacht af