[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