On 8/15/2011 6:06 PM, Ron Savage wrote:
Hi Steve
See below
On Mon, 2011-08-15 at 09:12 -0400, Stephen Woodbridge wrote:
On 8/14/2011 11:41 PM, Ron Savage wrote:
Hi Folks
http://savage.net.au/Perl-modules/html/genealogy/uuid.html
Let the replyfest begin!
Ron,
Overall this is a great start, here are some comments:
Importation of GEDCOM data
When a file of GEDCOM data is imported, various cases arise:
o Importation into an empty system
In this case, UUIDs do not need to be geneated.
I think this is only true if the empty system does not support UUIDs,
otherwise it needs to create at least one top level UUID to reflect the
importation. This would be identical to the case of having an empty
system and adding INDI(s) to it.
Hmmm. Not sure about this.
I guess this raises the question: Is that UUID meant to represent the
source or the new db?
This is a good question and I tried to answer it with my implied question:
Given an empty system, what happens when you add the first INDI?
I would assume that the act of importation would be similar to creating
an INDI. Also if the imported GEDCOM had UUIDs then you would import
them. Would you create an extra import action UUID, probably not needed,
but I think you are right to create one for the import action because
all imported entities would then inherit that UUID and be tagged for the
future that they came from that act.
I was thinking only that a UUID would be generated on demand, but I'll
reconsider.
Pauses a moment ... The source I'd say, so yes, probably better to
generate one at importation time.
Nice job.
Thanx. Errrr - Your reply stands out in the deafening silence :-)).
OK, well I'll throw out another thought that I had on this for
discussion. It has to do with optimization of UUIDs for storage purposes
in the GEDCOM. This seems risky, as it implies looking up some hierarchy
of structure that is not clear to me to find the UUID for some given
item. While this might be very straight forward in an object oriented
system that supports inheritance, I'm concerned that this might be:
1. difficult to do in/with a GEDCOM file
2. while it decreases spatial complexity, it increases algorithmic and
time complexity
3. it might be error-prone or hard to verify algorithmic correctness
4. it might be expensive to find the UUID for a given item
OK, so these concerns are somewhat abstract at the moment, I think they
warrant at least some thought and you might want to consider supporting
GEDCOM import/export where all items are tagged with their UUIDs.
Although, I can imagine that that would double or triple the size of the
GEDCOM generated. If you can generate both, then this could be used to
generate test cases to validate the correctness of other software.
Anyway I did mention this originally, because it seems like a valid
optimization, so I'm not suggesting that you change anything, but I
thought it worth while to raise this point to see what others might
think about it.
-Steve
