On 24 Apr at 12:01, "Adrian Bruce" <[email protected]> wrote: > My apologies to those who are bored by GEDCOM but its existence is > fundamental to our ability to transfer data other than in human-only > readable form. It concerns me that genealogical and family history > societies are letting software people make the running on whether or > not GEDCOM is replaced / enhanced / left to die. > > For what it's worth as a former IT professional of 30y standing > writing and supporting software: > > Caroline said "when software developers blame the exporting program > they abdicate their own responsibility to their customers". I > certainly applaud those who tweak their software and hope they'll gain > the market share they deserve. But we need to distinguish between the > general responsibility to their customers of providing the optimum > software and the responsibility to produce GEDCOM that is compliant to > a standard. This responsibility exists and lies with the person who > writes the export code. There are 2 reasons for this - if they call it > a GEDCOM export, it should be that, not a half-hearted attempt. > Secondly, if there are (say) 20 popular programs out there, and you > write a 21st, you seriously do not want to be writing 20 different > import routines plus your own export - one export and one import ought > to suffice. > > Sue said "Identifying "incorrect" GEDCOM is difficult because the > specification is not entirely clear." I'd disagree. For the most part, > the GEDCOM standard is perfectly clear and it annoys me that so many > sling around the view that GEDCOM is flawed. (I suspect Sue, from her > phrasing, doesn't belong to the extreme mud-slingers, though). > Certainly, the casual reader will not find it at all clear - but > that's not the target audience. In the BetterGEDCOM Wiki, it proved > hard for any of the IT literate contributors to find an "error" in the > specification - about the only one that sticks in my mind is that one > could have an infinite loop of a Source referring to a standalone > Note, which is justified by the first Source, which would refer to the > same standalone Note, which is... > > This is NOT to say that GEDCOM is adequate for family history today. > It isn't. The point is that all the new standards in the world won't > help if the major problem is not with GEDCOM but with the fact that > developers either can't be bothered to read the standard properly or > can't be bothered to take all the steps necessary to reformat their > own data to fit into the GEDCOM model. Neither of those problems will > be fixed by a new or enhanced standard. > > In essence we need a 2-pronged approach - firstly we need to highlight > the incompetencies of software suppliers who can't be bothered to > understand the difference between CONT and CONC in a GEDCOM file. > Secondly we need to agree on what family historians want from a > revision / replacement of GEDCOM. (If we want anything). For instance, > US genealogists tend to emphasise the data that goes into citations - > are UK family historians satisfied with what they have in GEDCOM? > Alternatively are we happy that FamilySearch will drive GEDCOMX (say) > and only produce something to satisfy FS's needs? > > Adrian Bruce I agree with all that you say. The crux of the matter is the software developers who write faulty programs to export and import GEDCOM. Thinking further about this, I cannot see the Family Search people doing anything to improve GEDCOM 5.5. But what is needed for any version of GEDCOM is a method of testing that a genealogy program correctly handles it. Let's try this: 1. A standard GEDCOM file should be developed that incorporates all the features of GEDCOM. For GEDCOMX this can only be done by that team. 2. The first test of compliance for any software is that it should be able to receive in this standard file, create a genealogy in their own format and then export from their program the GEDCOM. The exported GEDCOM should be identical to the standard one. 3. The second test of compliance for any genealogy software is that the program should be used to construct all the features that the developers have incorporated. Then a GEDCOM should be created to export the data. The first sub-check of compliance should be to then import this GEDCOM and check that the recreated genealogy file is identical to the original. The second sub-check of compliance should be to then import the GEDCOM to another program that is otherwise known to be compliant and then export from that another GEDCOM and finally import the last GEDCOM into the program under test and check that the regenerated genealogy is identical to the original. I would expect to hear squeals of protest from the software developers. We would depend on the reviewers and journalists to do or commission these relatively simple tests in any report they made on the various genealogy programs. A little pressure there? -- Tim Powys-Lybbe [email protected] for a miscellany of bygones: http://powys.org/

There is as described by Adrian an "infinite loop" - he'll know it as the techie phrase "deadly embrace" - however not just at the low level mechanic of conversion but at the business model end. New genealogical software entrants will be focused on "new business" and therefore should have an eye on the correct acceptance of files from the market share gorillas. The gorillas will reach a tipping point where holding on to market share and future income streams from existing customers will matter more than new business - in time it's generally harder to acquire new business customers than to do something for existing customers who might lapse. So the gorillas will attempt to set a lowish figure for investment in maintenance and compliance issues and more into new features - to justify extra income for "leaps" in releases (rather than steps with versions). So how much are the established players going to be concerned with their ability to conform to standards which mean that it is easier for customers to leave? The biggest gorilla should set the market standard with say a new version of GEDCOM and invite everyone else to play catch up... they could keep replaying such a trick - ensuring their new features are handled by the new standard of GEDCOM. If my thought process has merit then there are perhaps two parallel options 1) Assist the gorilla to produce a new GEDCOM that helps them to maintain and improve their market share 2) Assist the biggest known independent "influencer" of genealogical software purchasers (a kind of Which?) - by geographic region... The software companies and developers know how to do this stuff; the question is what is the incentive to their executives and shareholders to act in a way that both benefits them and the genealogical community at large? Find a juicy morsel here and you'll get a proper standard that is adhered to for solid business reasons. Mike Flaherty [email protected] On 24 Apr 2012, at 16:38, Tim Powys-Lybbe wrote: > On 24 Apr at 12:01, "Adrian Bruce" <[email protected]> wrote: > >> My apologies to those who are bored by GEDCOM but its existence is >> fundamental to our ability to transfer data other than in human-only >> readable form. It concerns me that genealogical and family history >> societies are letting software people make the running on whether or >> not GEDCOM is replaced / enhanced / left to die. >> >> For what it's worth as a former IT professional of 30y standing >> writing and supporting software: >> >> Caroline said "when software developers blame the exporting program >> they abdicate their own responsibility to their customers". I >> certainly applaud those who tweak their software and hope they'll >> gain >> the market share they deserve. But we need to distinguish between the >> general responsibility to their customers of providing the optimum >> software and the responsibility to produce GEDCOM that is compliant >> to >> a standard. This responsibility exists and lies with the person who >> writes the export code. There are 2 reasons for this - if they call >> it >> a GEDCOM export, it should be that, not a half-hearted attempt. >> Secondly, if there are (say) 20 popular programs out there, and you >> write a 21st, you seriously do not want to be writing 20 different >> import routines plus your own export - one export and one import >> ought >> to suffice. >> >> Sue said "Identifying "incorrect" GEDCOM is difficult because the >> specification is not entirely clear." I'd disagree. For the most >> part, >> the GEDCOM standard is perfectly clear and it annoys me that so many >> sling around the view that GEDCOM is flawed. (I suspect Sue, from her >> phrasing, doesn't belong to the extreme mud-slingers, though). >> Certainly, the casual reader will not find it at all clear - but >> that's not the target audience. In the BetterGEDCOM Wiki, it proved >> hard for any of the IT literate contributors to find an "error" in >> the >> specification - about the only one that sticks in my mind is that one >> could have an infinite loop of a Source referring to a standalone >> Note, which is justified by the first Source, which would refer to >> the >> same standalone Note, which is... >> >> This is NOT to say that GEDCOM is adequate for family history today. >> It isn't. The point is that all the new standards in the world won't >> help if the major problem is not with GEDCOM but with the fact that >> developers either can't be bothered to read the standard properly or >> can't be bothered to take all the steps necessary to reformat their >> own data to fit into the GEDCOM model. Neither of those problems will >> be fixed by a new or enhanced standard. >> >> In essence we need a 2-pronged approach - firstly we need to >> highlight >> the incompetencies of software suppliers who can't be bothered to >> understand the difference between CONT and CONC in a GEDCOM file. >> Secondly we need to agree on what family historians want from a >> revision / replacement of GEDCOM. (If we want anything). For >> instance, >> US genealogists tend to emphasise the data that goes into citations - >> are UK family historians satisfied with what they have in GEDCOM? >> Alternatively are we happy that FamilySearch will drive GEDCOMX (say) >> and only produce something to satisfy FS's needs? >> >> Adrian Bruce > > I agree with all that you say. The crux of the matter is the software > developers who write faulty programs to export and import GEDCOM. > > Thinking further about this, I cannot see the Family Search people > doing > anything to improve GEDCOM 5.5. But what is needed for any version of > GEDCOM is a method of testing that a genealogy program correctly > handles > it. Let's try this: > > 1. A standard GEDCOM file should be developed that incorporates all > the > features of GEDCOM. For GEDCOMX this can only be done by that team. > > 2. The first test of compliance for any software is that it should be > able to receive in this standard file, create a genealogy in their own > format and then export from their program the GEDCOM. The exported > GEDCOM should be identical to the standard one. > > 3. The second test of compliance for any genealogy software is that > the > program should be used to construct all the features that the > developers > have incorporated. Then a GEDCOM should be created to export the > data. > The first sub-check of compliance should be to then import this GEDCOM > and check that the recreated genealogy file is identical to the > original. The second sub-check of compliance should be to then import > the GEDCOM to another program that is otherwise known to be compliant > and then export from that another GEDCOM and finally import the last > GEDCOM into the program under test and check that the regenerated > genealogy is identical to the original. > > I would expect to hear squeals of protest from the software > developers. > We would depend on the reviewers and journalists to do or commission > these relatively simple tests in any report they made on the various > genealogy programs. A little pressure there? > > -- > Tim Powys-Lybbe > [email protected] > for a miscellany of bygones: http://powys.org/ > > ------------------------------- > 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

On 24/04/2012 15:38, Tim Powys-Lybbe wrote: > The crux of the matter is the software > developers who write faulty programs to export and import GEDCOM Absolutely! The issue is poor quality software from all the current developers. Compliance with the standard, be it GEDCOM or GEDCOMX, is vital. I believe there are some GEDCOM validators written by third parties, but there is not one that has gained acceptance as a benchmark. The development of the new GEDCOMX standard offers the opportunity to produce a validator as the same time. Going back to my web HTML example in my previous message, you can check if a web page complies with the HTML standard (http://validator.w3.org/). A similar tool for GEDCOMX is needed as a priority so that developers, users and reviewers can check for compliance with the standard. Once we can easily check, we can hold software developers to account. So, my plea is that you tell Familysearch what you think. They are asking for collaboration and feedback. Here is some links to get you started: http://www.gedcomx.org/Home.html http://familysearch.github.com/gedcomx/feedback/2012-03-23.htm <http://familysearch.github.com/gedcomx/feedback/2012-03-23.html> Sue Adams