Caroline, as a skilled and experienced genealogy software user, you get to your destination. To use a car analogy, you are a skilled driver. GEDCOM is part of what makes the software work, the things under the bonnet. Chris and others have taken a look under the bonnet and see that things could work better. Both viewpoints are valid, important and not mutually exclusive. "In FTM I ignore the source templates and create my citations using just the citation detail and citation text fields." So, you have chosen to ignore an essential feature that does not work properly? Why do you accept this? "Yes, every program creates its own weird and wonderful version of GEDCOM but the really important thing is how the importing software handles those quirks. I think when software developers blame the exporting program they abdicate their own responsibility to their customers. It is not difficult to examine a GEDCOM file produced by another program, identify the non-standard aspects and adapt the import for those files accordingly." I disagree. What about the self same developers responsibility to produce GEDCOM files that can be read easily? Identifying "incorrect" GEDCOM is difficult because the specification is not entirely clear. Catering for every permutation of GEDCOM that currently exists is extremely difficult as many have not been documented. As for keeping up with new versions, well, that is probably impossible. The "can do" responses from developers are only the fixes that are easy to identify and fix. More difficult fixes don't get done. "This may be because they have entered only a "standardised" place name in the place field and put the place details in the description field." The data model on which GEDCOM is based does not include a separate field for place names. This is an example of one of the more serious flaws in the underlying data model. "The Holy Grail of a perfect GEDCOM standard,perfectly implemented, is unattainable. Which is why those developers who make it easiest for potential customers to import their data from another program warts and all will continue to have a significant business advantage." I agree that perfection is unattainable. However, GEDCOM is very far from perfect. Developers who make real technical progress, rather than tinkering may win market share in the long run. Standards in computing are now widely recognised as fundamental, but that was not always the case. An example is the World Wide Web Consortium (http://www.w3.org/) which is the organisation that specifies web programming languages (e.g. HTML, XML). That does not mean that all web pages comply and web browsers (e.g. Internet Explorer, Firefox, Chrome, Safari) all try to interpret the non-compliant code. Users don't care unless the page does not work properly. Developers loathe writing pages for the browsers that do not follow the standards, because each deviation requires extra work. The least compliant browser still has significant market share, but is loosing out to other more compliant browsers because users get a better experience with them. Standardisation in genealogy software was a major theme at the RootsTech conference in February. Take a look a Jay Verkler's keynote speech Inventing the Future, As a Community <http://rootstech.org/> Sue Adams On 22/04/2012 20:29, Caroline Gurney wrote: > On 22 April 2012 13:27, Christopher Gray > <[email protected]> wrote: > >> Caroline - it depends on what you are including in the GEDCOM. For example, >> while I can export from TMG using GEDCOM I know that the citation and source >> details I have will not be effectively transferred. > Chris - I use both TMG 7 and FTM 2012. Problems arise exporting > sources and citations if you use either program's built in source > templates. That is because the template fields are exported as > separate GEDCOM elements and then cobbled back together incorrectly by > the importing program. > > In FTM I ignore the source templates and create my citations using > just the citation detail and citation text fields. These export as a > whole in a GEDCOM and therefore import correctly into the receiving > program. You could achieve the same in TMG by creating your own simple > templates with just one field. > >> I have received GEDCOMs >> from people using FTM and I have a number of problems with them - including >> how the place names are stored. > This may be because they have entered only a "standardised" place name > in the place field and put the place details in the description field. > Place names are stored as they are entered and, if entered in this > split fashion, will export accordingly. You might like to look at the > place list on my website: http://www.carosfamily.com/places.php to see > how places entered in full in FTM 2012 export correctly in a GEDCOM. > >> Different programs have different ways of >> handling relationships (e.g. step-children, same-sex marriages), places >> (e.g. including latitude and longitude) and such as DNA. So I certainly do >> not expect GEDCOM to be able to handle everything. > I entirely agree. You only have to read Tamura Jones' acerbic reviews > of genealogy software to realise there isn't any program which gets > GEDCOM "right". He lambasts them all. But I feel his approach misses > the point. Yes, every program creates its own weird and wonderful > version of GEDCOM but the really important thing is how the importing > software handles those quirks. I think when software developers blame > the exporting program they abdicate their own responsibility to their > customers. It is not difficult to examine a GEDCOM file produced by > another program, identify the non-standard aspects and adapt the > import for those files accordingly. A couple of years ago I > experienced an outstanding example of this "can do" approach from Mike > Voisin of GED-GEN. When I told him that a non-standard GEDCOM was not > importing correctly he issued an upgrade specifically designed to deal > with the problem. Darrin Lythgoes of The Next Generation has taken a > similar approach and his program correctly interprets GEDCOMs from a > wide range of different genealogy programs. He also provides the > facility to edit the handling of non standard GEDCOM tags post import. > >> Nor do I expect >> developers of any future version of GEDCOM to be able to handle all the data >> types / events / relationships that all programs use. It will be an >> improvement on the current version - but I certainly do not expect any way >> near perfection. > You are so right. The Holy Grail of a perfect GEDCOM standard, > perfectly implemented, is unattainable. Which is why those developers > who make it easiest for potential customers to import their data from > another program warts and all - using GEDCOM or a propietary utility > such as Wholly Genes' GenBridge - will continue to have a significant > business advantage. > > Caroline Gurney > > > ------------------------------- > To unsubscribe from the list, please send an email to [email protected] with the word 'unsubscribe' without the quotes in the subject and the body of the message >