Ìn de gedcom staat:

1 OBJE
2 FILE HuwelijkscontractHuwelijkscontract JG-AvH-beeld.pdf
3 FORM pdf
GEdInline meldt:
*** Line : Invalid content for OBJE tag: '' is not a valid
*** Line : Tag FILE is not allowed under OBJE
Het document is wel goed op de site gekomen (in mijn gewone site; bij Johannes Gunningh; https://www.genealogieonline.nl/genealogie-gunningh/I2640.php).

Ik heb gekeken of dit een oplossing is:
1 OBJE @O1@

0 @01@ OBJE
1 FILE HuwelijkscontractHuwelijkscontract JG-AvH-beeld.pdf
2 FORM pdf
GedInline meldt dan:
*** Line : Invalid content for FILE tag: 'HuwelijkscontractHuwelijkscontract JG-AvH-beeld.pdf' is more than 30 characters, the maximum ...
*** Line : Invalid content for FORM tag: 'pdf' is not a valid ...
De bron komt dan ook niet goed over. 

Is er een andere methode om Gedinline tevreden te stellen, of moeten we constateren dat de 'fout' alleen voor de validator een probleem is.
 

De titel had beter : Objecten in gedcom kunnen zijn

@ Tobias,

Je kunt de titel zelf aanpassen. Klik rechtsonder je eerste bericht op - bewerk en pas de titel vervolgens naar wens aan.

mvg-Ben

We gaan er naar kijken, u hoort nog.

Het is erg handig voor andere lezers die ook geïnteresseerd zijn om er ook bij te vermelden welke Versie er in de Gedcom staat.

Tussen onderlinge (wat vage en veel vagere versies) is er op dit vlak ook wel wat gewijzigd., in volgorde binnen de OBJ tags

Aangeven wat voor versie geeft veel duidelijkheid en kan er directer op gereageerd worden.

Groet Herman

5.5.1

Dan wordt de Gedcom standaard bij Ged-Inline niet goed geïnterpreteerd.

Aanvulling 04-02-2021: Of het versie nummer in de header is onjuist, i.c.m, volgorde van de OBJ tag

Dat zou heel goed kunnen, maar ik hoor het graag van Bob die nog steeds stelt dat de gedcom van GDP niet goed is.

toevoeging eerdere opmerking

De melding van GEDinline over het FORM en FILE zijn correct. Dit heeft te maken met de GEDCOM specificatie die hopeloos achterloopt. Enerzijds zijn alleen bmp,gif,jpg,ole,pcx,tif,wav geldig bij FORM, pdf dus niet. Een FILE mag maximaal 30 tekens bevatten, dit werkte wellicht in de vorige eeuw, maar nu niet meer.

Het goede nieuws is dat stamboomprogramma's en diensten deze GEDCOM beperkingen massaal negeren, dus ook PDF's met lange bestandsnamen komen veelal goed door. U kunt deze meldingen, alhoewel correct, ook negeren. Wat eigenlijk geen goed nieuws is, want idealiter zou je een GEDCOM specificatie hebben die niet zo achterloopt, maar dat is een zeer lastig proces.

Dat is zeker een lastig proces en des te lastiger na te lezen in de spec.

FORM pdf staat ook niet in de Gedcom standaard versie 5.5.1 genoemd, maar dan wel weer in Gedcom standaard 5.5.1 AE Revsion 2

en dan hebben we ook nog een Versie .5.5.5 in het MULTIMEDIA_FORMAT genoemd

Het gaat bij mij ook meer om de vagere meldingen bij validatie, die komen niet consistent.

De scheidslijn (detectie begin) zou volgens mij moeten liggen in de lijn 2 VERS 5.5 in de header.

Hoe gaat Ged-inline daar nu mee om ?

Chronoplex (Heritage) gaat ook niet goed

Mvg. Herman

@Herman,

GED-inline kent de GEDCOM smaken 5.5, 5.5.1 en 5.5.5 (beta). De validatie geeft antwoord op de vraag of de input (het GEDCOM bestand) voldoet aan de (in het GEDCOM bestand gemelde versie van de) GEDCOM specificatie. Omdat het een geautomatiseerd proces is, kunnen de opmerkingen wat cryptisch zijn, maar zijn dus altijd te relateren aan de specificatie.

Volgende punt is, wat doe je met de meldingen. Sommige, zoals de FORM pdf en langere bestandsnamen zijn al veel langer een probleem. De standaard had allang aangepast moeten worden op dit punt, maar ja, dit proces heb ik net in een ander topic beschreven.

@Bob, Dat andere topic heb ik gelezen en beantwoord.

De lange bestandsnamen liep ik direct in het begin van mijn onderzoek al tegen aan, omdat ik veel bestanden heb en heel veel lange namen, die al helemaal niet binnen Gedcom Versie 5.5 passen.

Terwijl dat binnen mijn antieke GENEALOG-systeem met de huidige besturingssystemen NTVDM MS-DOS of vDOS helemaal geen probleem is om die te bewerken en beheren. Zelfs in één stap voor ASCII, ANSI, UTF-8 en UTF-16 als output.

Er gloort wellicht wat hoop op dit punt: FamilySearch lijkt bezig met GEDCOM 7.0. Vorige week kwam dit uit, zou gepresenteerd worden op RootsTech, maar alle publicaties zijn weer teruggetrokken. Zie ook https://www.beholdgenealogy.com/blog/?p=3724

Ik heb al een naar de grammatica gekeken en een vergelijking gemaakt, zie https://blog-en.coret.org/2021/02/gedcom-grammars-5-5-1-vs-7-0-rc.html  Onder andere op het vlak van datatypes is het een en ander veranderd wat dus ook de bestandsnaam beperking oplost.

Oh dat geeft hoop; dank voor deze Gedcom 7 melding; die was ik nog niet tegen gekomen.

Ik zal het blijven volgen, zodat ik er ook snel mee kan komen als proefkonijn.

Maar dat zal nog wel even op zich laten wachten.

Groet Herman

PS. Ik voorzie dat software makers niet snel mee zullen gaan.

Maar ik zou de oude versies dan ook zeker niet meer onderhouden als deze geautoriseerd is.

Heb je eindelijk rust voor echte uitdagingen, want die heb je zat (gezien je laatste mooie toevoegingen) en kan die kraan dicht..

GEDCOM Standard (familysearch.org)

Ter info: Opmerkelijk, mijn foto staat wel naast dit in te tikken bericht, maar niet naast het vorige bericht

Edit 18-03-2021 heeft met instellingen in het account van doen en is gecorrigeerd en pas zichtbaar bij nieuwe berichten

Beste heer Bos, Is uw vraag beantwoord / probleem opgelost? 
Zo nee, waar loopt u nog tegenaan? Zo ja, kunt u deze dan op 'opgelost' zetten?