GEDCOM XML and whatever happened to versi

ric
2009-06-21
2013-05-30
  • ric

    ric - 2009-06-21

    Hi,

    I am sure this has been addresses many times in the past, but it seems to me that the GEDCOM format is just crying out for a re-write to XML. It seems there was a partial attempt back in 2002 (tentative version 6.0, see Aaron Skinnard's paper at http://msdn.microsoft.com/en-us/magazine/cc188730.aspx and also Bill Kinnersley's attempt at http://www.sunflower.com/~billk/GEDC/index.htm\). But I can't see any recent developments.

    I know very little about the GEDCOM file format but it does seem stuck in the past. I understand there may be issues of intellectual property rights, copyright and so on with the existing version 5.5, but what is to stop a number of manufacturers/interested parties from developing a new XML standard that at least addresses some of the issues (e.g, same sex partnerships, same sex marriages, etc., etc.) people have been debating for some time?

    Why did previous attempts fail? What is to prevent a new standard emerging under Creative Commons? Or is more the case that absolutely no-one can agree anything?

    Regards,
    Ric

     
    • Anonymous - 2009-06-21

      Ric, I think you've hit the nail on the head, so to speak, with your last comment. There have been many attempts, but never any agreement (and yes, if you search these pages it has been discussed MANY times before).

      There's nothing stopping anyone from establishing a new 'standard' - but what makes it universally accepted? Thats the challenge, far more than what the spec actually contains. I suspect that the internet has made getting agreement harder too, with its huge and varied user base - I mean even the webs own standards (like css etc) are far from universally implemented.

      Think of the perhaps hundreds of gene software out there that would have to change if some new standard was established - and the costs to all those interested parties.

      When LDS first created GEDCOM, apart from the fact it was only ever intended for their own use (AFAIK), there was really no competitiion.

      So for now its what we've we've got, so we live with it.

       
    • Lester Caine

      Lester Caine - 2009-06-22

      http://groups.yahoo.com/group/GenealogyXML/
      There are a couple of formats on the table, but getting agreement is more of a problem. Matching GEDCOM facilities is easy, but everybody seems to want different sorts of 'bells and whistles' :(

       
    • Sempre

      Sempre - 2009-06-23

      On the same track of using XML for genealogy, PhpGedView already supports output to GRAMPS XML from the Clippings Cart and you can download entire GEDCOM in Gramps XML format.

      Had a look and can not see anyway to read the same GRAMPS XML back into PhpGedView, am I missing something?

      How difficult would it be to allow this?

      Forget GEDCOM lets go with GRAMPS XML (or something similar)

      The future is already here.

       
    • Anonymous - 2009-06-23

      To import a GRAMPS XML (or any format other than GEDCOM) "simply" requires someone with enough interest to write a completely new set of import code. Is there a GRAMPS devotee keen to try? This is open source software after all, so nothing is stopping anyone from doing it.

      As to "Forget GEDCOM, lets go with GRAMPS" - hardly sensible, give that >90% (I believe) of the world still relies on GEDCOM as  the main vehicle for transferring data between products.

       
      • Wes Groleau

        Wes Groleau - 2009-06-24

        Speaking of GRAMPS, do those downloads really import into GRAMPS?

        I ask, because I've never used GRAMPS, but I did do such a download out of curiosity, and I found it hard to believe it wasn't buggy.  Lots of XML tags using the same ID attribute, for just one perceived bug.

         
    • Sempre

      Sempre - 2009-06-24

      Ok kiwi_pgv, I've added a feature request to import a GRAMPS XML.  (https://sourceforge.net/tracker/?func=detail&aid=2811271&group_id=55456&atid=477082 )

      I do realize that GEDCOM is the most prevalent lossy format around, however from what I have experienced it generally is not even suitable for the purpose it was designed for and in my view, it is time to move on whether it be GRAMPS XML or one of the other formats that exist ( http://en.wikipedia.org/wiki/GEDCOM#Alternatives to GEDCOM ) 

      You have to start somewhere and if phpgedview was to support say GRAMPS XML it may solve many portability issues with data & files. As a user of phpgedview I would rather have a single data archive with my photos & genealogy data to manage , than have a separate gedcom and photos etc. Here's to making phpgedview  a better program.

      "Wes Groleau" yes the import into GRAMPS works, but from what I can see on the GRAMPS project they need more developers to sort out those perceived bug eg:Lots of XML tags using the same ID attribute (can you report that on their bug system?)

       
      • Wes Groleau

        Wes Groleau - 2009-06-25

        "can you report that on their bug system"

        A better question is "Should I?"

        It is "illegal" for two elements in an XML file to have the same ID attribute.  If PGV generates that, where is the bug?  Is it PGV generating invalid XML, or is it GRAMPS requesting invalid XML?

        If _every_ element has a change attribute and ALL have the time of download, is that a PGV bug or does GRAMPS expect that?

        If some events point three times to the same SOUR ID, is that a PGV bug or does GRAMPS expect that?

        Inquiring minds want to know....

         
    • Anonymous - 2009-06-24

      "I've added a feature request to import a GRAMPS XML. (https://sourceforge.net/tracker/?func=detail&aid=2811271&group_id=55456&atid=477082"

      I'm sure you feel better for that, but its unlikely to achieve much I'm afraid. None of the developers, or major users of PGV use GRAMPS, so they are not likely to find working on such a request very interesting, and thats a major driver for getting Feature Requests actioned.

      You need to find a GRAMPS devotee, with PHP / MYSQL / PGV experience to do the work. Then I am sure no-one will object to incorporating it into PGV as an option. Thats how the export option appeared.

      Re your comment  "I would rather have a single data archive with my photos & genealogy data to manage , than have a separate gedcom and photos etc."

      You really do only have one source for storing all those things now in PGV - its called a database. The GEDCOM file is of little use other than for import and export between PGV and the rest of the world. Thats why PGV now has the option to turn off "synch to GEDCOM". You don't 'need' to continually update, or even use a GEDCOM file anymore.

       
    • Anonymous - 2009-06-24

      Sempre, just another thought. When you talk about importing from GRAMPS file, we've been assuming you mean GRAMPS XML? PGV can of course import a GRAMPS exported GEDCOM file quite well.

       
    • Sempre

      Sempre - 2009-06-24

      Yes kiwi_pgv I feel a lot better and understand that it is just a wish.

      kiwi_pgv >  "PGV can of course import a GRAMPS exported GEDCOM file quite well."

      Sorry for the confusion, I was talking specifically about the "Portable GRAMPS XML Package"  which is described as "The file format Portable GRAMPS XML Package uses the extension .gpkg and is currently a .tar.gz archive including GRAMPS XML together with all referenced media." by the GRAMPS team.

      kiwi_pgv >  "You need to find a GRAMPS devotee, with PHP / MYSQL / PGV experience to do the work."

      Who do you recommend?

      If more people than myself are interested in phpgedview being able to restore from and create a .gpkg  - "Portable GRAMPS XML Package", I will help provide motivation for the development if someone comes forward.

       
      • Greg Roach

        Greg Roach - 2009-06-24

        <<Who do you recommend?>>

        A few weeks ago, I had an email from one of the gramps developers, asking if PhpGedView was interested in being able to import grampsXML data.

        I replied that yes we were, but that we had limited resources to implement this.

        There may well be code that can be reused for this purpose.

        But it will need a grampsXML devotee to drive this forward.  At the moment, the only thing I could do with a grampsXML export from PGV is re-import it back into PGV....

         
      • Lester Caine

        Lester Caine - 2009-06-24

        There are a number of things here when it comes to 'XML' and it does depend on what one is trying to do ...
        http://lsces.co.uk/wiki/index.php?page=Genealogical+Data+Model has a list of the current status of a number of sites that have published XML schemas in the past, but I need to updated it a little with the feedback I've had recently.
        The main push of the GenXML group is for a single schema that covers everything with everything stored in XML as well. Not something that I subscribe to as, just like GEDCOM, searching the raw data takes time, and an index of some sort really is essential. THAT is what PGV does nicely!
        Using XML as a transfer mechanism is - from my view - what it is designed for, and in theory it should not matter which XML format someone wants, they ask for a section of your tree - in xyz format - and the relevant data gets served up. If someone just wants a simple BMD tree, then that is all they get, but if you want a full history ...
        The PROBLEM comes when trying to ADD information which does not fit in other models. Do you simply ignore it or do you provide some more complex mechanism to move from one structure to another. Lets ignore that problem for the moment, maintaining the original record be it GEDCOM or some XML format is quite simple and is certainly the nice thing about the way PGV does it currently.
        My own area of interest is breaking the self contained 'model' and using external sources to provide key material. In particular using the likes of openstreetmap to provide a directory of place information. There we are now starting to handle historic changes, although yet again getting agreement is proving difficult, but being able to identify a location, and it's surrounding area is useful - and all the data contained there is provided in XML format ;)
        I don't see any particular problem importing and exporting xml rather than gedcom, and the use of a 'filter' like the one to limit the gedcom tags that are used will work well for XML as well.
        But first I need to restore Firebird as a database in PGV :(

         
        • Greg Roach

          Greg Roach - 2009-06-24

          <<But first I need to restore Firebird as a database in PGV :(  >>

          The latest development version of PGV should work with the PDO::Firebird driver automatically.

          I realise that this driver is described as "experimental", but unless a Firebird user wants to test it for us, we don't know if it works.

           
          • Lester Caine

            Lester Caine - 2009-06-24

            <<But first I need to restore Firebird as a database in PGV :( >>
            The latest development version of PGV should work with the PDO::Firebird driver automatically.
            I realise that this driver is described as "experimental", but unless a Firebird user wants to test it for us, we don't know if it works.

            Sorry - PDO is not I route I'm prepared to bother with ... But the current changes to PGV HAVE made it a lot more difficult simply to switch to ADOdb which is what I'm happily using in an older version of PGV. Until PDO starts to take cross database activity seriously it's simply another half hearted attempt at the problem. ADOdb covers the majority of the SQL crossover transparently without having to re-write everything every time ... and the switch to it previously was a doddle!

            Once all the changes have stabilised I will look at simply replacing PDO again ;)

             
    • Anonymous - 2009-06-25

      I should say upfront that all this is academic to me, as I rarely either import or export my GEDCOM file. It is in PGV and stays there. PGV services all my needs. So I am totally dis-interested in what 'standard' is used.

      However, I am mentally intrigued by comments like "if phpgedview was to support say GRAMPS XML it may solve many portability issues with data & files".

      What is it about GRAMPS XML that would achieve this? Surely whatever 'standard' is adopted, there will always be new versions that some software adopts while others don't, different user's interpretations, and errors in its use? Those are the problems currently experienced with GEDCOM. Why should ANY standard be different in that respect?

      Incidentally, and slightly off-topic, I currently have NO GEDCOM file on my system at all, an experiment I've been meaning to run for a long time. I've deleted it from my /index folder completely. So far, PGV continues to work perfectly. The only things I can't run are gedcom check and place-check, which is no surprise, because both of those run only on the old text file. If I feel a need to run those I will export a fresh copy from the DB. This of course also overcomes some peoples concern at their GEDCOM file being downloadable, or hackable. (This as a follow up to my earlier comment here "The GEDCOM file is of little use other than for import and export between PGV and the rest of the world."). I do of course run extensive backups, mirrored servers etc etc.. But then I'm sure everyone does that, don't they?

       
    • Stephen Arnold

      Stephen Arnold - 2009-06-25

      Kiwi, et al
      Amen. Even when the 'hobby' had a managing 'body', LDS, there was obvious dissension amongst the contributing members about the supposed standard. How is it now that, without any authoritative group, anyone wishes to 'bless' one interpretation or method of presentation over another.

      We're with you, having removed our GEDCOM some time ago, and pretty much sticking to PGV. I still use GEDITCOM to provide complimentary merges and renumberings for others on this site, and my users, as well as occasionally manage certain aspects of our four GEDCOMs, and to calculate relationships as it is lightning fast while PGV still seems to drag out this process, frequently timing out.
      -Stephen

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks