More KMyMoney peeking: is our file format clearly documented?

[Josh Sled]

On Thu, 2004-06-24 at 09:18, Derek Atkins wrote:

> *SIGH*
> 
> It would've been nice if they just decided to write a Qt frontend
> to GnuCash, but I can certainly understand why they don't.

Likewise... :/

> Nope, we don't have current DTDs for our XML data.  It would be nice
> if we did, but there had been little reason to create them as the xml
> code isn't dtd-driven.  HAD the xml code been DTD-driven it would've
> been nice....

I don't really know what "DTD-driven [XML [un]marshalling]" code means
... nothing jumps out to me as the "right" way to do that.

[ The key thing is mapping the element names  to in-memory
data-structures and the and leaf-node values to lexical
value-representations [i.e., a GncNumeric for 50 => "50/1"], which the
DTD can't represent. ]


Frankly, the way we do things on the parsing side is a pretty readable
approach:

struct dom_tree_handler spl_dom_handlers[] =
{
    { "split:id", spl_id_handler, 1, 0 },
    { "split:memo", spl_memo_handler, 0, 0 },
    { "split:action", spl_action_handler, 0, 0 },
    { "split:reconciled-state", spl_reconciled_state_handler, 1, 0 },
    { "split:reconcile-date", spl_reconcile_date_handler, 0, 0 },
    { "split:value", spl_value_handler, 1, 0 },
    { "split:quantity", spl_quantity_handler, 1, 0 },
    { "split:account", spl_account_handler, 1, 0 },
    { "split:lot", spl_lot_handler, 0, 0 },
    { "split:slots", spl_slots_handler, 0, 0 },
    { NULL, NULL, 0, 0 },
};

?

I wish the generation side was as direct, data-driven and -- ideally --
the same.  But even it is pretty readable, as well.

I'd encourage the KMyMoney people to just UTSL ... specifically
src/backend/file/gnc-*-xml-v2.[ch] is the place.

...jsled

-- 
http://www.asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`