New XML file format for QOF?

[Josh Sled]

On Fri, 2004-10-29 at 13:07, Neil Williams wrote:

> Only in that I'm hoping to have more than one app using this for data 
> interchange and I want the XML to be as generic and flexible as I can. 

Hmm.  This effort sounds to me like you want a format that says barely
anything, in order to be able to say anything.

> > What's wrong with your palm conduit just writing out gnucash's existing
> > format?
> 
> It doesn't allow other applications to join the party and benefit from the 
> maps already in place. e.g. GnuCash <-> pilot-link solves my problem, but 
> what if gnumeric or Evolution wants to join, rather than them writing exports 
> in GnuCash, pilot-link and gnumeric formats, they can just write one and the 
> map does the rest. One XML format per app, mapping to many other 
> applications.
> 
> Doing it that way would shorten the development time but also creates another 
> lock-in.
> 
> I want open data interchange, not customised export filters that need to be 
> re-written for every application and every update.

If pilot-link or Evo wants to output a gnucash transaction, they have to
understand the semantic of a "gnucash transaction". It's not too hard to
also understand how to map that transaction into XML; fwiw, the native
format that each application has might even _be_ the XML fragment...

Since each of those applications still needs to understand the "GnuCash
Transaction", I don't see how formatting that transaction one level
removed really helps...

Maybe I just haven't looked at QoF enough to realize how much better it
makes the world, but it seems like the problem just moved from "mapping
XML to/from gnucash objects" to "mapping XML to/from generic objects,
then mapping the generic objects to/from gnucash objects".  Even when
the latter two are one in the same, it's the same problem.

I guess the RPC/encoded serialization is trivial to generate and parse
from a QofObject -- but at the expense of all the nice properties of the
interchange format -- namely: a close semantic "fit" with the data,
which imparts readability, and a loose coupling from the object format,
which promotes resilance to change of the code.

> > There's no requirement that the palm conduit use gnucash's data 
> > model or object hierarchy...
> 
> ?? How can I write a GnuCash file with no AccountGroup hierarchy? Unless an 
> object is attached to a valid AccountGroup tree, GnuCash ignores it. That's 
> why the hierarchy druid had a bug all that time, it was loading 470 example 
> accounts into the default book which were hanging around in memory until the 
> program was quit, but they were never displayed or written to file in a Save. 
> It was only when my merge code iterated over ALL existing objects, not just 
> those attached to the root AccountGroup, that these accounts ever showed up.
> (Patch sent in 22nd Oct.)

Hmm. I wasn't talking about the data-format nor some
tangentially-related bug. 

You seemed to imply that because another app doesn't have the concept of
an AccountGroup, that it can't write out an XML format that does.  But
maybe I misunderstood you.

> > * do you really mean "bag", or just "collection"?
> 
> It's not really a collection in the sense of a QofCollection because it holds 
> everything, not just one type. Calling it a collection when it contains many 
> different QofCollection's would be confusing. To me, 'bag' gets across the 
> idea of it being without a fixed order or hierarchy, a simple output from a 
> qof_foreach iteration.

I wasn't saying "QofCollection", just "collection" [note the lowercase
'c' :) ].  "Bag" is somewhat ambiguous about typing, but I understand
your motivation.  Perhaps
<qof:stupid-xml-requires-a-single-root-element> ;) ?  Or maybe
<qof:data> ?

> It isn't in the GnuCash XML either, is it? That was just 
> <gnc-v2>

Well, the GnuCash XML is pretty horrible.  I wouldn't base anything new
on it ... it goes against most conventions of how XML should work.

...jsled

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