<<snipped>> In England, 1 January was known as New Year's Day from at least the Middle Ages. OED gives a quote from 1393: 'The frosti colde Janever, Whan comen is the newe yeer'. Other forms of year started on other days, including the civil or legal year which started on 25 March, and formed the basis for most of the dates written in years AD. ... Double dating of the form you mention was used to avoid ambiguity; I've seen it quite widely used in documents from the late 16th century onwards. <<snipped>> Andrew, Thanks for this. I'd actually seen that Wikipedia reference but was looking for Leap Year references so skimmed over it, missing the significance of when the new year could be said to start. I suspect the thing I really hadn't twigged was that double dating isn't a modern invention to translate their dates to ours, but something used back then, implying more than one year number system then. What's interesting is that it tends to split the year number away from the calendar in a sense - indeed, "Other forms of year started on other days" suggests that different people would have different year numbers. Which makes using regnal years (e.g. 5th year of the reign of King ...) rather less perverse than my tidy mind imagined. If you have several (well, two) year number systems, what's one more? And the ordinary peasant in the street becomes more disconnected from the year number, suggesting that the inability of people to know their exact ages is not only forgetfulness but also a disconnect from the year numbers that would tell them. Fascinating stuff, Adrian B

> From: Adrian Bruce > Sent: 05 May 2012 17:20 Yes. > ... And if so, why? The explanation on Wikipedia is a good one: http://en.wikipedia.org/wiki/Julian_calendar#New_Year.27s_Day When Julius Caesar introduced the Julian calendar, the year started on 1 January (the calends of January), and calendar years continued to do this, with leap days every fourth February. In England, 1 January was known as New Year's Day from at least the Middle Ages. OED gives a quote from 1393: 'The frosti colde Janever, Whan comen is the newe yeer'. Other forms of year started on other days, including the civil or legal year which started on 25 March, and formed the basis for most of the dates written in years AD. 25 March was the celebration of the Incarnation of Christ - a point from which it is quite logical to count years Anno Domini. Double dating of the form you mention was used to avoid ambiguity; I've seen it quite widely used in documents from the late 16th century onwards. Best wishes Andrew -- Andrew Millard - [email protected] Bodimeade genealogy:   http://www.dur.ac.uk/a.r.millard/genealogy/Bodimeade/ My family history:     http://www.dur.ac.uk/a.r.millard/genealogy/ GenUKI Middx + London: http://homepages.gold.ac.uk/genuki/MDX/ + ../LND/

... And if so, why? This query arises from the Family Historian Users mailing list where someone found a reference in a parish register to 29 February 1743, which, after double checking, was clearly 29 February 1743 OS / 1744 NS. Now, 29 February 1743 (the form as written) didn't seem like a valid date at first until someone said it's 29 February 1743 OS / 1744 NS and it certainly would be a valid Leap Year in 1744 NS. Which made sense to me for all of 30 seconds until I asked myself the question - What's a New Style date got to do with it? Surely the effective calendar for identifying Leap Years in England was the pre-1752 Julian calendar when it would be Feb 1743, not divisible by 4 and therefore not a Leap Year? As one of the list members said, "It is not very scientific, but a Google search for 29 Feb 1743 finds lots of entries and many of them use 29 Feb 1743/44 format." I checked this and am looking at a Googled entry for a Nottingham University catalogue entry referring to a "Quit claim in respect of the portion of Isabella Countess of Carlisle charged upon the Byron estate in Nottinghamshire; 29 Feb. 1743/4". So it's used in England. Can anyone say what's going on? Was 29 Feb 1743/44 a Leap Year Day? And why? For instance, did the definition of a Leap Year move to using a New Year starting on 1 January earlier than 1752? Is the answer the same in Scotland as in England? (I just have this vague idea that Scotland moved to a 1 Jan date for New Year before England - if so it would have been inconvenient to have had the 2 Kingdoms 1 day apart for 25% of the time, between their two Leap Years) Thanks for any clarity Adrian B

Hi Marion, Magdalena is a member of the Yorksgen List and regular updates the Yorkshire surname list, she lives in Portugal so may be able to help you. Magdalena GORRELL GUIMARAENS <[email protected]> Good luck and happy hunting Annette WATSON Lismore Austra;ia At 05:44 AM 03/05/2012, you wrote: >I wonder if anyone can help me, please: I need help with research in >Porto and, possibly, Lisbon. >I have three birth and death record entries to check - I know the >precise dates but would like all the detailed information in them - >and I have further research to do too. The ideal would be someone >able to help me to go through the records when I am next out >there. Does anyone have any ideas, please? > >Thank you very much. > >Marion Watts. > >------------------------------- >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

Hi Marion, There is helpful information about Portugal family history research at the FamilySearch wiki for Portugal https://www.familysearch.org/learn/wiki/en/Portugal. It has information about civil registration as well as Catholic Church Records, some of which can be searched online on the free www.familysearch.org website. The wiki is a work in progress which has many helpful links to help you with your research. Donna Fraser -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: May-03-12 12:01 AM Message: 1 Date: Wed, 2 May 2012 20:44:42 +0100 (BST) From: Marion Watts <[email protected]> Subject: [SOG-UK] Research in Portugal. I wonder if anyone can help me, please: I need help with research in Porto and, possibly, Lisbon. I have three birth and death record entries to check - I know the precise dates but would like all the detailed information in them - and I have further research to do too.? The ideal would be someone able to help me to go through the records when I am next out there.? Does anyone have any ideas, please?? Thank you? very much.? Marion Watts.

I wonder if anyone can help me, please: I need help with research in Porto and, possibly, Lisbon. I have three birth and death record entries to check - I know the precise dates but would like all the detailed information in them - and I have further research to do too.  The ideal would be someone able to help me to go through the records when I am next out there.  Does anyone have any ideas, please?  Thank you  very much.  Marion Watts.

*The Family History Information Standards Organisation*, (FHISO) was formed in February 2012 (see http://fhiso.org/). It is a non-profit organisation, international and is independent of the various developers. GEDCOMX will be/is an _open _standard, so copyright is not an impediment (see http://en.wikipedia.org/wiki/Open_standards). I think it would be appropriate for SOG to participate in and contribute to both of these initiatives. In particular, it would benefit British researchers to have thier views taken into account in the development of standards and consequently future software. British researchers do some things differently to thier American counterparts. At the risk of sounding like a broken record, I am going to mention RootsTech <http://rootstech.org/>again. Since the first RootsTech conference in 2011 brought together software developers and genealogists, big things have been happening, such as the two things mentioned above. Sue Adams On 25/04/2012 07:10, Barry Faiers wrote: > I would caution against going down the British Standard/ International > Standard route. I too sit on British Standards Committees. I agree that > accuracy would probably be the result, but the time factor is horrendous. > To develop the standard would take at least 3 years for a British > Standard and probably 10 years for an International standard. > > Once published the Standard would be the property of and copyright of > the standards organisations. Any alterations would take years to > implement and would be out of the hands of genealogists, who are after > all, the people that the standard was written for and is used by. The > genealogy fraternity would loose control of 'their' standard to > bureaucrats. Currently Standards cost about £5 per page to purchase and > that includes front cover and back cover and foreword, definitions, and > a blank page if an odd number of pages is taken up. A 20 page standard > currently costs £96! I suspect that a GEDCOM standard would run to at > least 100 pages, and the discussions over definitions would take many > meetings to sort out before work on the standard could begin. > > If I remember correctly the 'County codes' were made into a British > Standard, and every FHS screamed because of the cost of purchase and the > copyright issues. > > Barry Faiers > > > > On 24/04/2012 22:08, Rod Moulding wrote: >> If GEDCOM or GEDCOMX is indeed an "international standard" SoG and others >> should be pressing for it (them?) to be taken under the wing of the >> International Standards Organisation (ISO), of which the UK member >> organisation is the British Standards Institution (BSI). Some may demur on >> the grounds of time and even bureaucracy, but from experience at UK and >> European level I know that great care would be taken, that individuals from >> all important and relevant organisations would be involved, and that the >> result would be a genuine and accepted standard. >> >> Rod Moulding >> >> > > ------------------------------- > 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 Apr at 22:08, "Rod Moulding" <[email protected]> wrote: > If GEDCOM or GEDCOMX is indeed an "international standard" SoG and > others should be pressing for it (them?) to be taken under the wing of > the International Standards Organisation (ISO), of which the UK member > organisation is the British Standards Institution (BSI). Some may > demur on the grounds of time and even bureaucracy, but from experience > at UK and European level I know that great care would be taken, that > individuals from all important and relevant organisations would be > involved, and that the result would be a genuine and accepted > standard. I suspect that the FamilySearch project will have sufficient difficulties coming up with an agreed result. Then we can all explore how it is in use and start the process of cajoling the software vendors to join the party. At that stage it might become appropriate to think further about developing the new GEDCOM standard into an International Standard and I do not think it should be broached seriously yet. -- Tim Powys-Lybbe [email protected] for a miscellany of bygones: http://powys.org/

On 24 Apr at 21:13, Sue Adams <[email protected]> wrote: > 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> Thanks for that. I have filled in the feedback form with some proposals. (It took a couple of hours to get a bit of a hang of the site!) -- Tim Powys-Lybbe [email protected] for a miscellany of bygones: http://powys.org/

I would caution against going down the British Standard/ International Standard route. I too sit on British Standards Committees. I agree that accuracy would probably be the result, but the time factor is horrendous. To develop the standard would take at least 3 years for a British Standard and probably 10 years for an International standard. Once published the Standard would be the property of and copyright of the standards organisations. Any alterations would take years to implement and would be out of the hands of genealogists, who are after all, the people that the standard was written for and is used by. The genealogy fraternity would loose control of 'their' standard to bureaucrats. Currently Standards cost about £5 per page to purchase and that includes front cover and back cover and foreword, definitions, and a blank page if an odd number of pages is taken up. A 20 page standard currently costs £96! I suspect that a GEDCOM standard would run to at least 100 pages, and the discussions over definitions would take many meetings to sort out before work on the standard could begin. If I remember correctly the 'County codes' were made into a British Standard, and every FHS screamed because of the cost of purchase and the copyright issues. Barry Faiers On 24/04/2012 22:08, Rod Moulding wrote: > If GEDCOM or GEDCOMX is indeed an "international standard" SoG and others > should be pressing for it (them?) to be taken under the wing of the > International Standards Organisation (ISO), of which the UK member > organisation is the British Standards Institution (BSI). Some may demur on > the grounds of time and even bureaucracy, but from experience at UK and > European level I know that great care would be taken, that individuals from > all important and relevant organisations would be involved, and that the > result would be a genuine and accepted standard. > > Rod Moulding > >

If GEDCOM or GEDCOMX is indeed an "international standard" SoG and others should be pressing for it (them?) to be taken under the wing of the International Standards Organisation (ISO), of which the UK member organisation is the British Standards Institution (BSI). Some may demur on the grounds of time and even bureaucracy, but from experience at UK and European level I know that great care would be taken, that individuals from all important and relevant organisations would be involved, and that the result would be a genuine and accepted standard. Rod Moulding -----Original Message----- From: Blair Southerden Sent: Tuesday, April 24, 2012 9:27 PM To: [email protected] Subject: Re: [SOG-UK] GEDCOM I agree with Adrian's comments BUT I also have a number of years experience in the UK IT industry including the management of software development and the management and support of software products. If the propositions are correct that a well defined specification for GEDCOM exists it would now be considered 'old hat' for each of twenty (?) software suppliers to be developing their own version of export file. Rather it would be far better for a single organisation such as SoG to have one export routine developed to meet the specification and with interfaces for the suppliers to tailor it to their individual products. Whether a separate import routine would be needed for each supplier, or whether a single one, again with a tailorable interface, would work, I am unsure. Of course we must not lose sight of the fact that this is an international standard so it's not immediately clear to me where the 'lead' may sit. Rather than putting pressure on a multitude of suppliers it would be better leadership for one organisation to accept responsibility for the development and recover the costs from either donations from each of the companies or from a licensing fee. Though I would suggest that this should actually become freeware that is available to anyone who wants to licence it, in order not to exclude new entrants to the market. Best regards Blair Southerden CEng. FBCS. CITP. ------------------------------- 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

<<snipped>> 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. <<snipped>> Tim - actually, I doubt that any serious software developer, by which I mean the actual coders themselves, would have the slightest objection to your idea, as it's a fairly standard idea, known as round-tripping. The squeals are more likely to come from the guys running the companies who would want to redefine the question to the benefit of their software. Mentioning no names but one company would protest that interfacing to online trees is more important. In truth, round-tripping is only a component of the test suite as it's possible that a misunderstanding cancels out - for instance, I might have misunderstood which was baptism and which was christening. Such a mistake is likely to be reflected in both my import and my export, thus getting us back in the same place. Which is why your 2nd set of tests (use the software to create the data) is also important. The issue is that, while your tests have a simple principle, there's a lot of data there to be compiled. While there are bloggers who have GEDCOM files of an evil size to load as tests, I doubt there is any guarantee of a percentage coverage of the GEDCOM standard. In addition, the test data needs to be compiled in such a way so as to hit all possible combinations - you can't just tick every feature off, because if you load items 1, 2 and 3 OK, that's no guarantee that 1 followed by 3 won't cause the import to crash. So - all do-able - but time consuming. Adrian B

I agree with Adrian's comments BUT I also have a number of years experience in the UK IT industry including the management of software development and the management and support of software products. If the propositions are correct that a well defined specification for GEDCOM exists it would now be considered 'old hat' for each of twenty (?) software suppliers to be developing their own version of export file. Rather it would be far better for a single organisation such as SoG to have one export routine developed to meet the specification and with interfaces for the suppliers to tailor it to their individual products. Whether a separate import routine would be needed for each supplier, or whether a single one, again with a tailorable interface, would work, I am unsure. Of course we must not lose sight of the fact that this is an international standard so it's not immediately clear to me where the 'lead' may sit. Rather than putting pressure on a multitude of suppliers it would be better leadership for one organisation to accept responsibility for the development and recover the costs from either donations from each of the companies or from a licensing fee. Though I would suggest that this should actually become freeware that is available to anyone who wants to licence it, in order not to exclude new entrants to the market. Best regards Blair Southerden CEng. FBCS. CITP.

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

One thing that has not been mentioned so far in this thread is that a GEDCOM file is only a simple text file. You want to know if your new program will import everything from your old program. Open a new file in your new program and enter data into every available field including source material, making sure that you follow the program's instructions (use a fictitious person or a real one if you have one that has information for every field). Do the same with your existing program. Export a GEDCOM file from both programs and open them in a text editor to compare any differences. Most differences can be 'remedied' using the SEARCH and REPLACE facility in Word (although you must remember to save the resultant file as a simple text file with a .GED extension). Always experiment with a copy of your existing file, never the original. An example that springs to mind is as follows: Old program: 1 OCCU 2 TITL Plasterer 2 PLAC Manor Park, ESS 2 FROM 16 Sep 1899 New program 1 OCCU Plasterer 2 DATE 16 Sep 1899 2 PLAC Manor Park, ESS Use SEARCH and REPLACE to globally find ^p2TITL (where ^p is a carriage return) and replace it with nothing. In the same way, exchange 2 FROM for 2 DATE. Date and place are the wrong way round, and this is the tedious bit. Highlight from 2 PLAC to the end of the date line and use the sort facility to reverse the order. This may take quite a while, but quicker than typing it all in again! I know this doesn't solve the fundamental problem, but it is a workaround. And if you are into even the most basic programming, you could make all these changes with one pass. Jeanne Bunting 3472 Attersley -----Original Message----- From: Dave Beakhust Sent: Tuesday, April 24, 2012 5:17 PM To: [email protected] Cc: [email protected] Subject: Re: [SOG-UK] GEDCOM (was Upgrade from FTM2006?) Confirming that files are "identical" itself presents a challenge. For example, given earlier comments about inconsistency with spaces, does one interpret all white space of whatever length as "space"? Does one ignore or warn about trailing spaces? To enforce (say) that a hash of the file should match exactly is a severe test. Maybe it is even undesirable, depending on whether you allow flexibility on reading files but try to write only files in canonical form. Example: a placename: New Milton Should this match New Milton ? (probably a bad example but I don't have gedcom spec handy) A better example may be treatment of space between a tag and its value... Dave Beakhust Sent from my iPhone On 24 Apr 2012, at 15:38, Tim Powys-Lybbe <[email protected]> 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 ------------------------------- 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

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 (similar to 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. 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 Apr at 17:17, Dave Beakhust <[email protected]> wrote: > Confirming that files are "identical" itself presents a challenge. For > example, given earlier comments about inconsistency with spaces, does > one interpret all white space of whatever length as "space"? Does one > ignore or warn about trailing spaces? To enforce (say) that a hash of > the file should match exactly is a severe test. Maybe it is even > undesirable, depending on whether you allow flexibility on reading > files but try to write only files in canonical form. Example: a > placename: New Milton Should this match New Milton ? (probably a bad > example but I don't have gedcom spec handy) A better example may be > treatment of space between a tag and its value... Very fair point. But the trouble about matching eg numbers of spaces is that a special match program has to be written to allow for such exceptions. Then that has to be validated. And a one month project would end up being five years and would probably never complete. I do not think it is difficult to say that the output GEDCOM should match the input one, precisely. > Dave Beakhust > > > Sent from my iPhone > > On 24 Apr 2012, at 15:38, Tim Powys-Lybbe <[email protected]> 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/

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

Confirming that files are "identical" itself presents a challenge. For example, given earlier comments about inconsistency with spaces, does one interpret all white space of whatever length as "space"? Does one ignore or warn about trailing spaces? To enforce (say) that a hash of the file should match exactly is a severe test. Maybe it is even undesirable, depending on whether you allow flexibility on reading files but try to write only files in canonical form. Example: a placename: New Milton Should this match New Milton ? (probably a bad example but I don't have gedcom spec handy) A better example may be treatment of space between a tag and its value... Dave Beakhust Sent from my iPhone On 24 Apr 2012, at 15:38, Tim Powys-Lybbe <[email protected]> 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 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/