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