Mhm, I'm not sure if I'd agree that internal representation should be completely independent of expected final output, if for no other reason than the implementation of that internal representation may or may not lend itself well to any given input or output, forcing the developer to spend more time rewriting those parts later. In other words, the input and output formts dictate parts of the creation (input) and manipulation (for later output).

If he implements, for example, in Tree::DAG_Node, he might get a slight improvement in ease of creation as he steps through his psuedo-GEDCOM files, he could still use XPath for searching (it's not just for XML), and he gets a few other features he may or may not have any use for (such as ascii-art representations of the tree), but if he ever wants to output to XML, he's going to have to completely rebuild that tree in a manner more accessible to an XML writer or hand-craft his own, as I don't know of any module that will do it for him automatically.

On a more primitive example, if he implements as a pure hash tree, he can directly modify every element by location and he can convert it directly to XML via XML::TreePP, but it's otherwise going to be a nuisance to manipulate, he gets no XPath searches, and he'd have to write his own tree walking code.

If he implements with XML::Twig, he gets XPath for searches, automatic XML output, and fairly decent tree manipulation functions, but he'd have to write a few small shortcut subs for things like adding a child or a sibling (since creating and pasting an element can take 2-3 lines perhaps better reduced to one), and of course writing a GEDCOM 5.5 file isn't going be any easier than with Tree — thought it also won't really be any worse.

There are a few decent tree-building modules available, but if he wants a tree generator/manipulator with easy XPath-language searches, automatic XML output, and preservation of node order, he's pretty much down to XML::Twig that I know of. Did you have another suggestion in particular?

(As an aside, I'd dispute that XML is only a file format -- sure, it's a file format primarily, but it's a file format that makes a richer view of the traditional tree easily human-grokkable. Trees are traditionally a collection of node positions, with little more metadata attached to that position than a name or value most of the time. XML trees are trees where the nodes can contain a subtree otherwise unrelated to the main tree containing an unlimited amount of metadata, and where as a result you don't have to think of it as a subtree if you don't want to, but can if you do. If you're working with complex trees and aren't optimizing for nothing but speed, you could do a lot worse than to think of your project in terms of how it would look in XML.)

(Aside #2: Whatever happened to GEDCOM 6.0 anyway? It was in 'any day now' state half a decade ago, but a quick Googling doesn't show anything ever coming out of it, and the only copies of the specification I can find are incomplete drafts.)