Received: by 10.36.140.3 with SMTP id n3mr4915508nzd;
        Mon, 28 Aug 2006 16:04:14 -0700 (PDT)
Return-Path: <John.Fin...@neumont.edu>
Received: from northfacemail2.northface.local ([65.114.212.237])
        by mx.googlegroups.com with ESMTP id h49si2686561nzf.2006.08.28.16.04.12;
        Mon, 28 Aug 2006 16:04:14 -0700 (PDT)
Received-SPF: neutral (googlegroups.com: 65.114.212.237 is neither permitted nor denied by best guess record for domain of John.Fin...@neumont.edu)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [BeyondGen] Re: GEDCOM 5.6 (was RE: [BeyondGen] File formats)
Date: Mon, 28 Aug 2006 17:03:22 -0600
Message-ID: <94B0B6D99C2381418360349500613693D1B485@northfacemail2.northface.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [BeyondGen] Re: GEDCOM 5.6 (was RE: [BeyondGen] File formats)
Thread-Index: AcbIun73O9N3LGr8RjaJFZIhkcYj3wCMap8w
From: "John Finlay" <John.Fin...@neumont.edu>
To: <beyondgen@googlegroups.com>


> > Everyone says that GEDCOM is bad.  I have been working with it for a
> > long time now, and I don't see anything wrong with the GEDCOM format
> > itself.  In many ways it is better than XML.  For example, it is
> > 30-40%
> > smaller in size than an equivalent XML format.
>=20
> And much harder to parse or process. The benefits of XML, IMO, trump
> file size, and for transmission and storage, Fast Infoset or some
> other binary XML can be used, or just zip/gzip/bzip.
>=20

Most of the tools needed to parse/process GEDCOM already exist and work
just as well as their XML counter parts.  Even with XML tools, you still
have to convert textual data into a binary data model.

IMO, XML will have a place in the world of Genealogy, just not as a
replacement for GEDCOM.

(Going off topic here, someday, as a purely academic exercise, I would
like to look into seeing how hard it would be to take Xalan/Xerces and
modify it to work with GEDCOM.)

> > There is not enough market/user driven demand for a replacement of
> > GEDCOM because GEDCOM is "good enough".  Without market demand,
> > then no
> > matter how good another standard is, there won't be incentive for
> > vendors to implement it.  There are already a lot of XML genealogy
> > formats out there.  Many of them have been around for several years.
> > But because the market perceives GEDCOM as "good enough" there is no
> > reason to pursue something else.
>=20
> Most commercial genealogy programs have no compelling reason to
> improve interoperability with their competitors. However, I think
> there is tremendous pent-up demand for it in from the consumers of
> genealogical data. I cringe every time I see a GEDCOM go around,
> because I know data is getting lost. I think the demand is there,
> just not by those with the power or ability to do anything about it.
>=20

As more web service based repositories of data open up online, it will
become more economically demanding for vendors to be interoperable.
Many Genealogy software vendors have yet to discover that genealogy
software is now a commodity and there is no longer money in developing
the software.  The money is in the data and software that enhances the
data.  Google and E-Bay are the examples from other industries.
Ancestry.com is getting closer. The new FamilySearch is also moving in
this direction.

Data loss is not intrinsic to GEDCOM.  The data loss is caused by
programs dropping data from the GEDCOM because they don't know how to
fit it into their data model.  The same data loss problems would occur
with any intermediary data transfer format.

> There's already a GEDCOM 6.0 XML beta, apparently abandoned [1], that
> would be a good start, though it is copyrighted by the LDS Church, so
> not sure about the legalities. The GenealogyXML list found the GEDCOM
> data model to be lacking, and attempts to "fix" GEDCOM seemed to
> leave people unsatisfied. And without a sponsor/champion, many felt
> that acceptance of an improved GEDCOM would not be likely outside of
> a few small circles--there's just no compelling need for the
> commercial vendors to put the work into it.
>=20

There is no compelling reason to put the work into writing tons of code
to support a new XML standard.  But I think we could get software
developers to make a few small changes to the GEDCOM support that they
already have.  It should be easier for developers to work in 2 or 3
small changes into their next release.

Also with a large open community behind it, the developers could get
support from other developers on how to implement it decreasing the
overhead.

Another big incentive would be marketing.  The software vendors would
want to have their software listed as an approved GEDCOM application on
the official GEDCOM website and would not want to have it listed as
being poor in GEDCOM support.

> Working code tends to overcome many obstacles, so perhaps an open
> parser/writer of an improved GEDCOM 6 would lower the barrier of
> entry enough to spur adoption.
>=20
> > Since the market says that GEDCOM is good enough, then let's fix
> > GEDCOM!!  Does anyone else think we could get a community built up
> > to do
> > this?
>=20
> I think an improved GEDCOM would be better than nothing. Getting a
> community would be pretty easy, the GenealogyXML is full of ideas and
> suggestions. The hard part is consensus and getting enough people to
> do the hard work.
>=20

I have followed the genealogy data model problem for quite some time and
I am very aware of the strong opinions and factions that are out there.
Getting consensus is near impossible, which for me is just another
reason why we should work to improve the GEDCOM that we already have.

If we start small and make a few changes at a time, it won't be long
before we all get to where we need to go.  And it will be easier to get
people to work on several smaller projects than to work on one huge
project.

--John