New XML file format for QOF?

[Neil Williams]

On Friday 29 October 2004 5:15 pm, Josh Sled wrote:
> On Fri, 2004-10-29 at 04:48, Neil Williams wrote:
> > The main difference is that I would like to use the XML for data
> > interchange between QOF applications and to make the format more like a
> > simple bag than a tree:
>
> "bag vs. tree" isn't really the problem, is it?

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. 

OAF may provide an alternative anyway.

> 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.

> 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.)

> * 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.

> * the outer element isn't namespaced [<qof:bag>?]

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

> * the "-v1" isn't really necessary -- that could very well be in the
>   namespace.
>
> * the "version=x.y.z" is probably not necessary, either...

Copied straight from GnuCash XML. I admit it's not ideal and there are 
considerations around collisions but it'll be a while before this hits the 
code anyway, there's plenty of time to iron out things like that. However, 
GnuCash doesn't validate the namespace at the moment (unless I've missed 
something).

> * is a "book" a first-order concept in QOF?

QofBook can encapsulate everything held in storage and provide the 'natural' 
place for working with a storage backend. Everything in QOF exists within a 
book and without a book, nothing can be retrieved, queried or set (when you 
try, QOF either fails or creates a book for you).

> > This way, the XML can hold any compatible QOF data.
>
> I suggest you take a look at RDF, which attempts to do something
> similar, but I think more effectively.

It would mean another layer within QOF to convert the QOF objects into RDF 
objects - there's also little point in adding RDF support to QOF/GnuCash when 
this kind of XML with no Doctype or Schema is already in use. I'd only need 
small changes to existing files to parse the example.

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20041029/56b2bf8e/attachment.bin