QSF XML file backend for gnucash-gnome2-dev branch

[Josh Sled]

I wanted to echo Derek's comments: nice job!  :)

On Tue, 2005-01-25 at 11:38, Neil Williams wrote:

> I've got code in the patch just sent to gnucash-patches to correctly 
> distinguish a QSF XML file from v1, v2 or the older binary GnuCash text 
> formats and it loads using the QofBackendProvider mechanism rather than as a 
> GnuCash module.

A question came up on the IRC channel regarding this process... Can you
elaborate on how it's done?  Is the namespace [or lack thereof, in the
older XML case] of the file being opened used to branch on which backend
to use, or some other process?


> The patch includes the QSF schema for object and map files, it includes code 
> to install the schema in a qsf sub-directory of $prefix/share/ and it also 
> includes a test QSF map that will be the next phase of development to map 
> pilot-link QOF objects into GnuCash objects.

One problem I wanted to call out was the use of the URIs
"urn:qof-qsf-map" and "urn:qof-qsf-container" as the XML namespaces. 
Not only are they not registered URN namespace, but best practices are
to use a namespace-name which is generally resolveable [i.e., an
http-scheme URI], and which resolves into a useful document [i.e., is a
URL].

I'd recommend something date-stamped under http://qof.sourceforge.net/ 
... maybe: 

    xmlns:qsfMap="http://qof.sourceforge.net/ns/qof/2005/01/qsf/map#"
    xmlns:qsfContainer="http://qof.sourceforge.net/ns/qof/2005/01/qsf/container#"

... each of which is probably simply an HTTP redirect [303] back to the
documentation.


> The backend can cope with partial QofBooks and is designed to handle routines 
> that create a second QofSession, populate that session with data for export - 
> any QOF compatible objects - and save the session to export as QSF XML. There 
> is absolutely no requirement for AccountGroup or any other specific object to 
> be present, the backend will write out just invoices or just accounts, just 
> customers or any mix.

A better way to say this might be: "it is the caller's responsibility to
ensure to the consistency, validity and coherence of the sub-set of data
being serialized".


> QSF increases the libxml2 requirement to 2.6.0 for the gnome2 branch to 
> support the schema validation which identifies QSF files relative to existing 
> files.

Is this the only reason for 2.6.0?

Can we make schematic validation optional?

Can we get rid of it entirely?


> QSF uses UTC time throughout and uses this time format string:
> #define QSF_XSD_TIME   "%Y-%m-%dT%H:%M:%SZ"
[deletia]
> The datestring must be timezone independent and include all specified fields.

To clarify:

* MUST the timezone be in UTC, or MAY it be in some non-UTC timezone, 
  as per [1]?
* If it MUST be, do you intend to fully support xsd:dateTime, or no?

[1] http://www.w3.org/TR/xmlschema-2/#dateTime


> as well as QOF_TYPE_DEBCRED as a QOF_TYPE_BOOLEAN currently. The parameter 
> will be converted back during the creation of the QofObject concerned.

Hmm.  I'm assuming debcred is actually an enumerated value; is the
intent to support that, or just to use boolean?

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`