John Dobson wrote:
Darren: GEDCOM was not designed or ever used as a database design /
schema. It was designed and sill operates today as a database backup
format.
Yes, and that's my point. At least my understanding is that GEDCOM is quite
limited as to what kinds of information it can represent, and if you have any
other kinds of information, you can't back up your entire database into GEDCOM.
In fact my perspective on databases is that it is the external formats, fully
documented and designed for interchange, that are the ones most important to be
complete and comprehensive, and any separate format used natively to a program
is just a performance optimization.
So my main project here is actually a new interchange format, and having a
better application is more incidental to that, as a reference implementation.
If you are developing a serious genealogy database you better
have an option to import / export GEDCOM or your product will not passed
first base.
Of course. The new format will accurately preserve the intended semantics of
any data that GEDCOM or other genealogical formats can represent. But export
depends on the information.
Consider the new format effectively a superset of GEDCOM in capabilities, with
the same limitations mapping the two as when you map ASCII and Unicode.
Ron: take a look at www.webtrees.net this is pretty much where things
are at for web based, collaborative genealogy products.
Good to know.
------
Similarly, the main point of Muldis D is to be a comprehensive means to
represent both relational data and database-centric code in a unified portable
manner, like SQL but better; the DBMSs that implement it are second to this, and
the initial DBMS that I make is meant as a reference implementation; the focus
is on the language / data format, not on the program.
-- Darren Duncan
