[GNC-dev] Deprecation of XML file

Jim DeLaHunt list+gnucash at jdlh.com
Mon Sep 14 22:00:34 EDT 2020


Stefan:

On 2020-09-14 12:38, Stefan Bluhm wrote:
> Thank you all for the feedback. Let me please summarise your demands for XML and comment on that (I hope I didn't leave any comments out). Always keep in mind that in this case we are talking SQLite as a file type, just like XML. Not about the DB server library.

I don't feel like you have summarised all the points in favour of the 
current XML data storage format accurately, based on the emails I saw.

A few examples:


> 1) A save file has less management overhead than a DB.
>> SQLite is also file based and transparent for the end user. No DB management required. So here is no chance a tall.
> 7) A burden to require existing users to obtain and maintain SQLite. Other SQLs have their additional administrative overhead.
>> There is no additional administrative overhead (assuming the DBI library is included in GnuCash).

I don't know what you are referring to by "management overhead" and 
"administrative overhead". A point in favour of the static XML data 
format is that there is no need to install a database module separately 
from Gnucash.  I don't know what you mean by "DBI library". Maybe you 
mean, "SQLite is no worse than XML if we require that GnuCash includes a 
copy of SQLite with no extra work to install it and set it up", I could 
agree with that.


> 5) Use rsync for fast diff based backups.
>> Should the same with an SQLite.

I disagree. Diff-based backups can work differently on a text file than 
on binary files. An XML file saved as text is text-based, uses newlines 
for structure, and is basically linear. As far as I know, there is no 
option to save a SQLite database in text form, it is always binary and 
has opaque internal structure.


> 4) It can be easy analyzed by more advanced (XSLT, XPATH,…) commands.
>> Just use any SQLite browser. I claim that is a lot easier than fighting with XSLT/XPATH etc (this is certainly opinion based)

This claim does not explain what a SQLite browser can do. Also, I am not 
yet persuaded that a SQLite browser can do the kinds of finding and 
modification that XML tools can do with comparable ease. Note that in my 
use of the XML format, I have modified and fixed, not just "analyzed" 
(which I understand to be read-only).


> 6) XML is a well defined format, while SQLite is not ISO complete.
>> SQLite also has a defined file format. It might not be an ISO standard but it is well defined.

The point I was trying to make about ensuring GnuCash data can persist 
for decades is that use of XML helps because it is more transparent 
(because it is text-based) and more accessible in the absence of GnuCash 
software and all the supporting software from the era when the file was 
created. By contrast, binary application-specific data formats tend to 
be much harder to read and understand in the absence of the supporting 
software. This has nothing to do with ISO standardisation of the format. 
It has a little to do with the breadth of tools supporting the format — 
the more tools for the format, the greater the chance that some will 
still be usable after decades. Whether the format is "well defined" 
today is not terribly important, because lots of information about 
formats gets lost in the course of years and decades.

It seems clear to me that the inherent properties of XML-format data 
make it more robust over decades than binary app-specific formats like 
SQLite.  I don't think its the even comparison which you portray.


So, I don't think you have persuaded me that a) you have fairly 
summarised the points in favour of the XML format, or b) that SQLite is 
as good as or better for the requirements expressed in this thread.

Best regards,
        —Jim DeLaHunt



More information about the gnucash-devel mailing list