On 06 Dec 1999 12:02:47 CST, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]> said:
> Christopher Browne <[EMAIL PROTECTED]> writes:
>
> > The alternative is to create a language that is "completely
> > platonic" in being totally unaware at all times what the output form
> > will be. That would mean we have to then create a separate
> > translator, and effectively add a further sorta-language to the mix.
> > I think it rather preferable to keep it pretty simple, having the
> > operators inside be device-independent.
>
> After reading the stuff you've been writing and thinking about it
> more, I realized that I was arguing for exactly what you describe. I
> was only thinking at the step of going from your account group to a
> representation of just the data that should go in a particular type of
> report. For example:
>
> (report 'expenses-top-summary 2)
> ...
> ("Food" 300.0)
> ("Fuel" 50.0)
> ("Rent" 500.0)
>
> This file could then be used to generate a line-item report, or a
> graph.
Ah. My "lights" go on when you mention the word "graph."
I was (not inappropriately) fixated on textual representations, and
particularly in how one can construct columnar reports in a flexible
way.
I was assuming that I already had a way of "walking" through the
data in an orderly fashion. The existence of text-export.scm implies
(to me) that this does exist; if there is some good way of building
"data views" to establish summaries, that is a good thing that is
likely pretty much orthogonal to the "columnar reporting" set of
functions.
I've not thought hard about the data model, only about the
"managing columnar data" model.
> However, you're right, with this setup if we didn't want to have to
> add a new rendering backend for each output format every time we
> wanted to create a new report, we'd have to develop another
> "sorta-language" which specified "document structure". So generatng a
> report would be:
>
> account-group -> report-data -> document-structure -> rendered-document
>
> And the document-structure representation would look like the stuff
> you've been describing.
>
> Of course, the drawback to the method you suggest (I think, and
> correct me if I'm wrong), is that it's less geared toward those people
> who want to store their "report data" in a way that lets them mangle
> it as they please. Though perhaps that should be thought of as a
> separate issue, not synonymous with reporting...
>
> Thoughts?
If people want to store the data in some "alternatively-mangled" form,
then it seems to me that there are at least three directions we can take
to help them in this:
1. Allow the generation of summary and transaction reports in spreadsheet
form. Mangle as desired using Gnumeric (or whatever).
I'm suggesting this as one of the "standard" output forms.
2. Provide exports that produce "generic" output in a lightly-structured
form that is readily mangled for other purposes.
For instance, producing a tab-delimited file with a bit of metadata
up top provides something that people could use several ways:
--> Manipulate using Rand /RDB, a relational database system that
works with tab-delimited files
--> Ditto, with NoSQL, which is more-or-less Rand /RDB-compatible
--> Load into a RDBMS
--> Load into a spreadsheet
3. Provide exports in a more strongly structured form. XML, to be
more specific.
None of these forms should be prohibitively difficult to produce;
given some sort of "data model" (as you describe above), these should
all be quite readily produced as not terribly complex Guile scripts.
--
The *Worst* Things to Say to a Police Officer: Hey, is that a 9 mm?
That's nothing compared to this .44 magnum.
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
