GEDCOM 5.5 vs GEDCOM 6.0

[Dave Lester]

I've read previous discussions and debates about adopting an XML-based
standard for sharing genealogical data, which has made me wonder: why
hasn't anyone adopted the GEDCOM 6.0 standard?
http://www.familysearch.org/GEDCOM/GedXML60.pdf

Has XML been too large of a jump for software developers, or was
GEDCOM 6.0 never officially released? I've only been able to find a
draft version of the standard.

Thanks,
Dave Lester

[Jay]

My understanding is that the GEDCOM 6.0 standard was never really
finished. Looking at the document, I see it is just a draft. Plus,
if you think about it, there's no point in wasting valuable
development resources adding Gedcom 6 export/import to a software
product if none of the other major genealogy programs can export/
import it. Since the genealogy programs all speak GEDCOM 5.5 to one
degree or another, and it does the job of moving genealogy data
between programs, I suspect there isn't much incentive for genealogy
companies to spend the money to add this to their software. Of course,
I am not affiliated with any companies who make genealogy software, so
this is just my guess.

On Dec 4, 6:57 pm, Dave Lester <daveles...@gmail.com> wrote:
> I've read previous discussions and debates about adopting an XML-based
> standard for sharing genealogical data, which has made me wonder: why

> hasn't anyone adopted the GEDCOM 6.0 standard?http://www.familysearch.org/GEDCOM/GedXML60.pdf

[John Vilburn]

I think you are right, Jay. GEDCOM 5.5 may not be buzzword-compliant like
GEDCOM 6 is, but it gets the job done and is extensible. Any
incompatibilities in the way GEDCOM files are handled between genealogy
programs are not the fault of the GEDCOM spec. Incompatibilities are
primarily there because of differences in feature sets between the various
programs. And moving to a completely different format won't address that
problem.

Aloha,
John

[Dallan]

The GEDCOM 6.0 standard was abandoned by the LDS Church when they
started work on "New Family Search". The New Family Search data model
has departed far enough from the GEDCOM data model (you can't export
from NFS to GEDCOM for example) that it seems unlikely that the LDS
Church will update the GEDCOM standard in the foreseeable future.

I beg to differ about the GEDCOM 5.5 spec not being at fault for
incompatibilities in the way GEDCOM files are shared. Here are
several problems:

* The data model in the spec is way too general. No vendor implements
the full data model. If they did, their user interface would be way
too complex. So different vendors implement different pieces of it.
The problem this creates is that when reading another vendor's GEDCOM
you have to decide how to convert their model into your own.

* A case in point: look at how names are handled. According to the
model, you can either store the full name, individual name pieces, or
both. So what if your software stores name pieces but you get a
GEDCOM from a vendor that stores only the full name? You've got to
parse the full name into name pieces as part of the conversion
process, which can be problematic unless that vendor stores full names
with slashes around the surname (this is a convention and not part of
the model - not all vendors that store full names do this).

* GEDCOM 5.5 hasn't been updated in over 10 years. There's no way to
include multimedia objects for example. The most popular genealogy
program, Family Tree Maker, doesn't export pictures at all. The
others just include full path names to pictures, which makes sharing a
GEDCOM with pictures exceedingly difficult. How difficult would it be
to come up with a "GDZ" format, similar to KMZ or JAR, that bundled
pictures in with the GEDCOM? This seems like a no-brainer to me.

* There's never been a certification program or validation software so
that vendors could make sure that their GEDCOM exports conformed to
the GEDCOM standard. This isn't really the fault of the standard
itself, but is a big reason why we see bad GEDCOM's. For example,
when geni.com first started exporting GEDCOM's they were wrong: their
character set declaration was incorrect. They're better now, but a
certification program would certainly have helped them.

-dallan