Louis Kessler’s Behold Blog The Behold User Forum
Blog Comments
322.
Complete Genealogy Data Transfer - Blog comment by lkessler - 20 Jun 2015
Enno,
Well its not really like versioning. The previous version of the data needs to be passed ONLY when (1) the program does not support the feature in question, and (2) the data it subordinate to (i.e. dependent on) other data that the user has changed.
So there would never be two versions of any data. ...
323.
Complete Genealogy Data Transfer - Blog comment by ennoborg - 18 Jun 2015
Louis,
Interesting idea, which suggests that you think about a sort of versioning in the data layer. Is that what you mean? Preserving the data as it was before a change looks like versioning to me, because there is a chance that the process needs to be repeated when another application not supporting the ...
324.
Complete Genealogy Data Transfer - Blog comment by lkessler - 16 Jun 2015
Enno,
I agree with you. When a data item is edited, the attached non-handled data may not be relevant or may even be wrong.
But that doesn't mean the issue is unsolvable. One possible solution might be to require that the former pre-edited data be transmitted with the non-handled data as a separate event ...
325.
Complete Genealogy Data Transfer - Blog comment by ennoborg - 16 Jun 2015
Louis, I'm with arb, because I don't think the issues are solvable, except when unprocessed objects are completely isolated from the ones that are edited.
You mention the extreme example of a program that doesn't process sources, and I that's a perfect illustration. When you have a tree where for example an ...
326.
Complete Genealogy Data Transfer - Blog comment by lkessler - 13 Jun 2015
Will,
I presume you don't currently do extensive documentation of your sources, because I don' t believe Legacy, Geni/Myheritage and FamilySearch do a very good job yet of transferring sources between each other or into GEDCOM. GEDCOM is technically okay for sources, but most programs don't read them in well ...
327.
Complete Genealogy Data Transfer - Blog comment by qbuster - 13 Jun 2015
I agree with Louis. I do accept what arb is concerned about but, if I understand Louis correctly, I think you are missing the main point: main point is that if gedcom reader x doesn't recognise a chunk of data it should ignore it - pass on by and leave it intact.
For me this is a no-brainer. If I can't ...
328.
Complete Genealogy Data Transfer - Blog comment by lkessler - 10 Jun 2015
Arb:
Excellent! Now you're really starting to think about this.
The examples you give of data-pass through when an intermediate program doesn't handle something are solvable. As I said in my post, the concepts "must be sufficiently independent of each other" to help prevent such problems. What to do about ...
329.
Complete Genealogy Data Transfer - Blog comment by arb - 9 Jun 2015
Okay, let me try another tack... What you propose is potentially dangerous, and here's why:
* You create a data file using program A, A includes some non-standard attributes, which are exported as per the standard.
* The user then imports this file into program B, which does not support, nor even ...
330.
Complete Genealogy Data Transfer - Blog comment by lkessler - 9 Jun 2015
Well yes. A read-only program obviously need not export anything. But if it does, and if it expects other programs following the standard to read its export, then its export must not lose any data.
Sorry, but I'm very adamant on this point. This new standard must be rigid and must require data retention ...
Prev 311-320
Living Up To Expectations - Blog comment by robhoare - 21 Jun 2015