> > Everyone says that GEDCOM is bad. I have been working with it for aMost of the tools needed to parse/process GEDCOM already exist and work
> > 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.
> And much harder to parse or process. The benefits of XML, IMO, trump
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
(Going off topic here, someday, as a purely academic exercise, I would
> > There is not enough market/user driven demand for a replacement ofAs more web service based repositories of data open up online, it will
> > 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.
> Most commercial genealogy programs have no compelling reason to
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
Data loss is not intrinsic to GEDCOM. The data loss is caused by
> There's already a GEDCOM 6.0 XML beta, apparently abandoned , thatThere is no compelling reason to put the work into writing tons of code
> 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.
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
Another big incentive would be marketing. The software vendors would
> Working code tends to overcome many obstacles, so perhaps an openI have followed the genealogy data model problem for quite some time and
> parser/writer of an improved GEDCOM 6 would lower the barrier of
> entry enough to spur adoption.
> > Since the market says that GEDCOM is good enough, then let's fix
> I think an improved GEDCOM would be better than nothing. Getting a
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
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.