Hi Paul On Fri, 2011-08-05 at 11:52 +0200, Paul Johnson wrote: > On Thu, Aug 04, 2011 at 03:49:25PM +1000, Ron Savage wrote: > > > I've been thinking about how to develop our software libraries, and I'm > > thinking of formally requesting Gedcom2 as the parent namespace. > > With regard to the name I have a few thoughts. First, I don't > particularly like Gedcom2. It doesn't say anything to me about what it > is, apart from the next version of GEDCOM. But GEDCOM is already at > version 5.
Understand. Gedcom2 isn't great, but does indicate a link to history; it's just a suggestion after all. > However, without any suggestions my comments don't mean much. So I'll > give some suggestions which you can feel free to completely ignore. > > I know there is a trend nowadays for top-level namespaces. Back when I > wrote Gedcom.pm we didn't give the matter much thought. But were I > starting now, I might go for something like Genealogy::GEDCOM as my > namespace. Perhaps you would feel comfortable having your module under > the Genealogy top level? I nearly went that way. The only thing which stopped me was the length of the name. I like it, certainly. I should have mentioned it. So, if no-one particularly objects, I'd go with Genealogy::*. > Alternatively, if you are going to be keeping fairly close links to > Gedcom.pm (probably meaning that your module will use Gedcom.pm), > consider the now somewhat standard naming convention of > GedcomX::YourModule. Personally, I'd only ever adopt this naming style if my module was an eXtension of a pre-existing module (or set thereof). To me, GedcomX::* has to be limited to Gedcom. I was hoping for grander things :-). > > I do realize some programs, e.g. Gedcom.pm, don't add tags (at least I > > don't think it does) over and above Gedcom, they just manipulate what's > > provided in the data. > > You are correct that Gedcom.pm manipulates whatever tags it finds in the > GEDCOM file. Some tags obviously have a meaning defined in the spec, > and with these Gedcom.pm can perform specific relevant actions. Good - that's clear. > But one of my original design decisions was that no data should ever be > lost and thus Gedcom.pm will just pass through any tags it doesn't > understand, be they user-defined tags (prefixed with an underscore) or > application specific extensions. Also good. Such design decisions interest me. I just scanned the docs of a few Gedcom modules, and didn't see any statement to this effect, but I concur that data should be preserved. > However, you can add, delete and update any and all tags. There are > convenience functions for this on some known tags, but at a lower level > they can all be manipulated. You are correct though, that Gedcom.pm > doesn't add any non-specified tags unless you specifically ask it to. OK. Tags seem to dominate various discussions, and I think I now see why: With numeric data, each field's type tells you something, whereas with Gedcom-style data, the tags are playing the part of the type. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622
