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