GnuCash XML spec (for non-C languages?)

[Geert Janssens]

On 06-11-12 11:22, Christian Stimming wrote:
> Am Montag, 5. November 2012, 22:55:32 schrieb Geert Janssens:
>>> So IMHO the logical next step is to find some new formulation of the
>>> gnucash datastore where the data manipulation is no longer solely tied
>>> to a C library. I know this step isn't particularly easy, but I think
>>> the time has come to no longer outright refuse such a step.
> Unfortunately the engine unittests don't really help for the direction of
> thinking here. Those unittests only cover data access through our C library
> (and depending on glib), and my main point is that those new devices will want
> to access the data through some other means but surely *not* through the
> existing C library.
The unit tests won't solve the issue directly, no. But they are a 
prerequisite in cleaning up the C library. And that in my opinion would 
be a good help indirectly to clean up our business logic and hence make 
it easier to formulate the requirements for a language/platform 
independent access layer. That may take too much time though.
>
> Hence, even though it is still not yet realistic to find a complete
> specification of data store access independently from our C library, I think
> it should be possible to do a specification of a subset of the data. And
> applications that access and work on only that subset should then be possible.
> Such as, an Android app that access a gnucash SQL data base, and using only
> those specified features and data store elements. Voila, there we have our
> multi-user multi-platform gnucash within reach...
>
>
This appears to be thinking and planning way beyond my level of 
knowledge. I have no idea what steps are normally taken to come to such 
a specification and then how to encode it in a way that is 
cross-platform and language independent. So I'll probably continue to 
follow this direction of the discussion passively from here on. I'm not 
against any of this, I rather just have no clue on this matter.

Geert