QSF XML file backend for gnucash-gnome2-dev branch

[Neil Williams]

On Wednesday 26 January 2005 4:42 am, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > If you want that to be:
> > /opt/garfield/gnucash/share/xml/qsf/
> > and
> > /usr/share/gnucash/share/xml/qsf/
> >
> > That's easy. I used qsf/ to distinguish from any other xml formats.
>
> Uh, well, /usr/share/gnucash/share/xml/qsf is just wrong, regardless.

Duh, I really ought not to continue once I know I'm tired!

Of course, it would end up, currently, as /usr/share/qsf. Hmm, not ideal.

> /usr/share/xml/qsf

/usr/share/qof/qsf ? 

(/usr/share/xml already exists on my system, something to do with docbook and 
scrollkeeper.)

Seeing as QOF will have to be installed either within GnuCash or as a library 
for the others? I'll change QSF_SCHEMA_DIR to ${share_dir}/qof/qsf

> Fair enough...  In the long run I want to move completely away from
> XML as a "storage" format.  But that's still a ways away.

Agreed - GnuCash won't need to use QSF as long term storage, just for data 
interchange. XML is ideal for sharing data between users and applications. 
The QSF XML can be received, loaded, merged and then deleted. Only with 
applications like pilot-link would it need to be stored on disk for any 
length of time. They don't want the extra dependency of a SQL backend.

> Sure..  Get it working, then get the UI to work well around it.  A
> pretty UI without any guts is rather useless, no?  :)

My thoughts exactly.
:-)

> You don't have to go back to 2.5.2; but you should go back to 2.5.10.

Done. 2.5.10 it is.

> I dont understand?  Assume gnucash<->gnucash -- why is KVP so hard?
> (Keep in mind that I'm significantly less interested in
> gnucash<->non-gnucash ;)

:-( That's where the problems start!

> Why?  You know that a transaction note maps to 
> <kvp type="string" path="/notes">

Excellent! THANK YOU! I hadn't thought of using the path as an attribute. (I 
know, why didn't I look at the current format . . .  )

It would be:
<string type="kvp" path="/notes">content</string>

(as long as the forward slash character is legal in an attribute - I can 
substitute something else if need be).

> so I would think that would be relatively easy to map, 
> no?

It will be now, yes. It becomes just another parameter that certain 
applications will understand and certain applications can ignore.

> See josh's comment about validation.  IMHO (and in my personal
> experience) validation is a lot of overhead for very little gain.

Personally, I don't find schemas that hard to write, and once written, the 
code to validate them in libxml2 >= 2.5.10 is simplicity itself. I write the 
XML I want and keep hitting xmllint until the schema allows it!

Writing the QSF maps is going to be just as tricky initially - I'm hoping to 
develop a tool that can help, although knowing my GUI programming, it'll be a 
console app! (Think xf86config). OK, not quite as hard as that.
:-)

> Just throw an error when you actually parse the data if you see
> something in the document that you don't expect and can't handle.
> Gnucash has lived without validation for, what, 4, 6 years now?  Has
> it suffered horribly for the lack of validation?  I certainly don't
> think so.

Well, 2.5.10 is sufficient for me, I'd rather use what is available. I feel 
that GnuCash *has* suffered from using XML files that cannot be validated 
(even after adding the <xml version=... at the top) and my desire for schema 
validation is based on uses outside GnuCash as well as inside. It may work 
when only one application is creating these files - I can't see how it can 
work with lots. Reinventing all that code just to throw an error is not 
worthwhile - I have to keep a lid on the total amount of code in QOF and 
duplicating what already exists in a library that is already available on the 
target is just not sensible to me.

-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.neil.williamsleesmill.me.uk/
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/20050126/4f4167c7/attachment.bin