Hi Bob On Thu, 2011-08-04 at 15:44 -0400, Bob McConnell wrote: > The name GEDCOM2 implies that it will be a superset or evolution of the > existing format. However, due to the lack of standard semantics, the > original is not a sound base to build onto. For that reason, I suggest a > new name that doesn't have those implications.
Yes, I've been thinking about this. We can't use Gedcom, because installing a new module with an old name stops pre-existing scripts working. That's why I registered GraphViz2 when I re-wrote GraphViz, and why I chose Graph::Easy::Marpa when I re-wrote Graph::Easy. The latter simply pushes all new code into a sub-namespace, but the principle is the same. I don't support anything like Gedcom::NG (Next Generation), because it's too tightly tied to (looking like) it's intrinsically more Gedcom rather than better Gedcom, although some people might like it. But then, how to name modules which deal with import/export between the 2 - Gedcom::NG::Import::Gedcom etc or Gedcom::Import::Gedcom::NG. And so on. I feel every possible suggestion can easily be given a list of pros and cons. Pro for Gedcom2: o Gedcom2 is a warning that it's not Gedcom /but is closely related/, and Gedcom does stand for Genealogical Data Communication, and hence IMHO, is a well-constructed acronym. o Gedcom2 will be found in web/CPAN searches (for Gedcom), which is also part of the reason for choosing it, and not something like Data::Genealogical::*. o The 2 indicates something newer. o Being newer it aims to, and hopefully delivers, improvements just where users are dissatisfied with Gedcom. I don't see a fight over another namespace as being productive. Nevertheless, if someone can come up with a great (sez who?) alternative, then, yes of course, we can consider it. As for the semantic problem, you can't possibly hope to encode a solution to that in a namespace, can you? -- Ron Savage http://savage.net.au/ Ph: 0421 920 622
