* GEDCOM 5.5.5!

The place to chat and put the world to rights
Post Reply
User avatar
mjashby
Superstar
Posts: 442
Joined: 23 Oct 2004 10:45
Family Historian: V6.2
Location: Yorkshire

GEDCOM 5.5.5!

Post by mjashby » 04 Oct 2019 14:50

Some interesting background and info for those interested in these things:

https://www.tamurajones.net/GEDCOM555Ju ... sion.xhtml
https://www.gedcom.org/index.html

Not sure how much traction this might gain, if any, given the apparent lack of practical involvement of any of the major genealogy software producers, but at puts to shame the 'efforts' those so-called major players who have supposedly being reviewing/discussing/considering a replacement for GEDCOM for years and have produced precisely zero concrete results/output.

Mervyn

User avatar
AdrianBruce
Megastar
Posts: 875
Joined: 09 Aug 2003 21:02
Family Historian: V6.2
Location: South Cheshire
Contact:

Re: GEDCOM 5.5.5!

Post by AdrianBruce » 04 Oct 2019 16:42

I have yet to get my head around some of the strategic views presented in these documents - particularly the "how does anyone progress to v5.5.5?" aspect since a first glance says that they are not keen on polluting 5.5.5 software with 5.5.1 capabilities (still less 5.5 which they appear to dismiss). Perhaps. If I read it right.

In fairness to the supposed "major players who have supposedly being reviewing/discussing/considering a replacement for GEDCOM for years", I have actually seen little evidence of that discussion. There's been a lot of wishful thinking that someone else would do "what we are going to propose" and very little evidence that this thinking was based in reality. I say that having been induced to spend some time with the BetterGEDCOM initiative because it was claimed that the major players were indeed thinking of advancing at that time. In reality, it became clear that this was just wishful & self deluded thinking on the part of the organisers of the initiative.

Will it be any different this time? Well, why should it? I don't mean that cynically but realistically... Honest. I think....
Adrian

User avatar
AdrianBruce
Megastar
Posts: 875
Joined: 09 Aug 2003 21:02
Family Historian: V6.2
Location: South Cheshire
Contact:

Re: GEDCOM 5.5.5!

Post by AdrianBruce » 05 Oct 2019 12:32

So, after reading the initial part of 5.5.5's specification, I'm still confused and concerned about how practical it will be for software developers to progress to 5.5.5. Page 5 of the spec'n states:
A GEDCOM writer is code that writes a particular version (and encoding) of GEDCOM.
A GEDCOM reader is code that reads a particular version (and encoding) of GEDCOM.

A GEDCOM 5.5.1 writer is code that writes GEDCOM 5.5.1 files.
A GEDCOM 5.5.5 reader is code that reads GEDCOM 5.5.5 files.

A typical genealogical system contains multiple GEDCOM readers and writers, for the last few versions of GEDCOM.
(My emphases and inserted line-breaks.) What this does not do (so far as I could see) is define what a "genealogical system" is - is FH a single "genealogical system"? In which case it could indeed contain readers and writers for 5.5, 5.5.1 and 5.5.5. but I don't know.

The importance of this issue comes when you read things like
GEDCOM 5.5.5 readers need not accept errors known to occur in GEDCOM 5.5.1 files, and must not do so.
...
it is not possible to support GEDCOM 5.5.1 and 5.5.5 with a single combined reader.
...
The GEDCOM 5.5.5 reader need not and must not compensate for errors that are only known to occur in ostensible GEDCOM 5.5.1 and earlier files, and must keep things simple by rejecting invalid files.
Note that it says reject the files, not the erroneous lines.

So if FH has one, and only one, reader and writer, that reader has to be able to read in GEDCOM 5.5 and all sorts of files and not reject them. It therefore can never be a 5.5.5 reader. And it can only become a 5.5.5 writer (with a 5.5 reader) if it breaks some of the design principles it has followed and discards non-compliant GEDCOM - whereas now it will read the stuff in and preserve it as fossilised lines "just in case".

As I said, everything depends on that line about "A typical genealogical system contains multiple GEDCOM readers and writers". If FH does indeed qualify as a system, then it could contain multiple readers and writers and whichever one was to be used would be specified by parameter switches. If it doesn't qualify as a system - then how does FH and any application progress since a company will always want to provide the ability to read obsolete files?

If anyone can offer any interpretation or correction, I'd be interested.
Adrian

avatar
JohnnyCee
Platinum
Posts: 35
Joined: 14 Nov 2016 13:44
Family Historian: V6.2

Re: GEDCOM 5.5.5!

Post by JohnnyCee » 07 Oct 2019 17:22

Adrian,

By my interpretation, a single component in a genealogy application could implement multiple GEDCOM readers and/or writers so long as that component could be configured to support only one of the GEDCOM versions at a time. I do not know whether or not it is practical to do that and meet the requirements that the GEDCOM 5.5.5 spec establishes for v5.5.5.

User avatar
tatewise
Megastar
Posts: 16890
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: GEDCOM 5.5.5!

Post by tatewise » 07 Oct 2019 21:18

There is no fundamental reason why each reader & writer for each GEDCOM version cannot be a separate component of script. However, such components could/would/should share sub-functions that handled GEDCOM sub-structures that are identical in the different versions, e.g. DATE fields.

That would also be compatible with the concepts proposed by FHISO in such as their FHISO ELF Standards (16587).
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Valkrider
Megastar
Posts: 1110
Joined: 04 Jun 2012 19:03
Family Historian: V6.2
Location: Spain
Contact:

Re: GEDCOM 5.5.5!

Post by Valkrider » 08 Oct 2019 05:43

tatewise wrote:
07 Oct 2019 21:18
e.g. DATE fields.
A bad example @Mike as there is a new date format D M and no Y or that's how I read the spec.

User avatar
tatewise
Megastar
Posts: 16890
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: GEDCOM 5.5.5!

Post by tatewise » 08 Oct 2019 09:07

I have now inspected the 5.5.5 specification, and you are correct (but only for Gregorian Dates), although that does not totally invalidate my example, as 5.5.1 and 5.5 use the same DATE specification, and 5.5.5 has just that tiny variant that could be handled with a control parameter.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Valkrider
Megastar
Posts: 1110
Joined: 04 Jun 2012 19:03
Family Historian: V6.2
Location: Spain
Contact:

Re: GEDCOM 5.5.5!

Post by Valkrider » 08 Oct 2019 09:26

@Mike

See this from the 5.5.5 Press release:-

Birthdays
GEDCOM 5.5.5 explicitly allows what many applications were already allowing: a date without a year.
Centenarian Support
GEDCOM 5.5.1 allows recording someone’s age at an event, but its AGE_AT_EVENT definition restricts the number of years to only two digits. GEDCOM 5.5.5 allows three digits.

avatar
Woodg
Newbie
Posts: 1
Joined: 08 Oct 2019 09:28
Family Historian: V6

Re: GEDCOM 5.5.5!

Post by Woodg » 08 Oct 2019 09:36

The GEDCOM 5.5.5 specs contain this:

Birthdays: Dates without Years
The <DATE_GREG> definition has been expanded to include exact dates without a year; this acknowledges that we often know a birthday while being unsure of the birthyear.

User avatar
tatewise
Megastar
Posts: 16890
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: GEDCOM 5.5.5!

Post by tatewise » 08 Oct 2019 11:08

I treat press releases with suspicion, so I was looking at the The GEDCOM 5.5.5 Specification with Annotations PDF .zip file from https://www.gedcom.org/gedcom.html where it says on page 24:
Birthdays: Dates without Years
The <DATE_GREG> definition has been expanded to include exact dates without a year; this acknowledges that we often know a birthday while being unsure of the birth year.
Therefore it says on page 83:
DATE_GREG := <DAY> + space + <MONTH> among all the other established DATE definitions.

The Annotation on page 81/82 says:
Date without Year
The <DATE_CALENDAR> definition states that “When only a day and month appears as a DATE value it is considered a date phrase and not a valid date form.”
Not allowing dates without a year is an unfortunate decision, and one that remains unmotivated.
The reason is not that a value like 23 Aug is ambiguous, and could be understood to mean either the 23rd of August or August in the year 23; it cannot be interpreted as latter, because GEDCOM demands that years are at least 3 digits long.
It is quite common for people to know birthdays without knowing the birth year, or remember a death date without the death year.
Knowing a date is so valuable in search for documents that could contain the year, that applications should support dates without a year. GEDCOM readers should accept such dates, but issue a warning that the year is missing.
Centenarian Support
GEDCOM 5.5.1 allows recording someone’s age at an event, but its AGE_AT_EVENT definition restricts the number of years to only two digits. GEDCOM 5.5.5 allows three digits.

Interestingly, FH allows Age to have 4 year digits, and 4 day digits, and month up to 99, in violation of the GEDCOM 5.5 and 5.5.1 specifications, so FH is not 100% compatible.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

Post Reply