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
pgpfYmOI2mpMF.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
