QSF XML file backend for gnucash-gnome2-dev branch

[Josh Sled]

On Tue, 2005-01-25 at 18:29, Neil Williams wrote:

> The existing methods are used to identify the existing data file types. If 
> those all fail, then I parse the document using one of the QSF schema and 
> proceed from there. That happens in gnc-backend-file.c, lines 390 onwards:

Got it; thanks.  That seems about right.


> > 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.
> 
> I know. I'd appreciate any tips you have on registering a namespace, once a 
> suitable static URI is available - it's not yet.

To register a namespace:

Step 0: Make an http: URI.
[optionally] Step 1: Put valuable content at the end of the URI.

You can certainly use a URI before it's a URL.  If you're woried more
about long-term stability, then I recommend using a service like
<http://purl.org/>.


> I agree - this is a QOF backend and it will be used by pilot-link and 
> hopefully by other applications too - without GnuCash being installed. So it 
> would need to be somewhere on qof.sourceforge.net and only Linas has access - 
> I can't contact him, he hasn't been receiving email for a while.
> 
> It still needs to be installed with QOF for offline purposes, as expected.

Well, there's no particluar requirement that it actually resolve to
anything, nor that the content at the end of the URL be used in the
parsing process.  It's just good practice that it resolve to
_something_, and at this point, preferrably a human-readable something.


> > ... each of which is probably simply an HTTP redirect [303] back to the
> > documentation.
> 
> Which also isn't on sourceforge, it's on my own server. I wouldn't want that 
> to be the static URI, sourceforge is more likely to be sticking around!

Well, purl.org may be a bit-better-bet, then.  But, yes, sourceforge
would probably be quite good. 


> > > 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".
> 
> Quite - QSF will never write an invalid XML file, nor accept one for input. I 
> was just waffling, as usual.

Well -- and please correct me if I'm wrong on this -- it sounds like one
can create a session which only contains only a subset of a
self-[referentially-]consistent object graph, and serialize that
fragment.  It would be valid XML, but semantically invalid because of
missing data...


> > Can we make schematic validation optional?
> 
> No. It's fundamental to how QSF accepts and parses the data. It's not just 
> schema validation that needs 2.5.2, there are some xml constructs that came 
> in at the same time.

Hmm.  I've written many XML parsers, and none _required_ a schema
definiton to parse data....

It looks like you're doing the majority of the parsing as a side-effect
of the validation tree-traversal, but it doesn't seem like you
specifically _need_ to... Can you just switch from doing this during a
validation step to doing it during a normal tree-walk?

> Besides, I thought you were in favour of valid XML?

It certainly must be valid!  Doesn't necessarily need to be
_validated_,  however.  I.e., we don't need to compare the output XML to
some XML Schema definition [let alone a more reasonable
schema-definition language].

> I'd hate to write a DTD for this, the objects may be possible but the maps are 
> quite something else.

I'd rather see a shift toward RelaxNG than toward DTD.

> No. Although the code will handle it, the XML will not validate. IIRC, the 
> -0500 format won't validate, it would need to be -05:00. Try it with xmllint 

Yeah, "-0500" is wrong, as per xsd:dateTime.

> It's a nice idea but when you get up close with xmllint, you can't format the 
> timezone to validate without using regexps. It's easier to use UTC and Z.

"Without using regexps" where?

...jsled

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