It's been rumoured that Christopher Browne said:
> The problem here is that we have two choices:
>
> a) Define a report-writing language, or
> b) Define a report-writing language *as well as a language for
> representing device-independent reports.*
>
> The approach I'm suggesting is more like a). It involves only 2.5
> languages:
> a) Scheme,
> b) Report-writing functions layered atop Scheme (the 0.5), and
> c) The output form. (ASCII, HTML, LaTeX, Gnumeric XML, ...)
>
> It we want to generate reports in a pure device-independent form,
> and *then* transform them into the physical output form, then
> the answer is probably to generate reports using XML, and then
> use transformation tools on the XML.
>
> The problem is that this requires an extra programming language, as the
> set of "languages" increases to four:
> a) Whatever we use to generate the XML,
> b) The XML DTD/Schema for the dev-independent intermediate form,
> c) Whatever language is used to transform XML into output forms, and
> d) Output form languages.
>
> I don't see a whole lot of merit in adding the extra layers.
> Feel free to disagree, but also feel free to justify the need for
> the extra "language layers."
Simpler is better. If, after a few years, some dominent infrastructure
evolves for displaying. printing and distributing documents in multiple
formats, we can switch to that. There seems to be active work and
development elsewhere on these fronts, but the dust seems far from
settled.
--linas
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
