Document Templating / Report Generation solution?

[Christopher Browne]

On Sat, Feb 21, 2009 at 6:25 PM, S P Arif Sahari Wibowo
<arifsaha-/E1597aS9LQAvxtiuMwx3w at public.gmane.org> wrote:
> On Fri, 20 Feb 2009, Christopher Browne wrote:
>>
>> "procedural" sorts of things (e.g. - opening files, databases, and such),
>
> Thanks for the comment! Yes, it is procedural, but a pretty established
> routine:
>  open / connect to database,
>  query for the first grouping,
>  loop on the first grouping,
>   ...
>     query for the n grouping,
>     loop on the n grouping,
>       query for the details,
>       loop on the details
>       end loop
>     end loop
>   ...
>  end loop
>  close database

None of that's surprising, and none of that is particularly plausible
to do using LaTeX.

It's a macro language intended to transform bits of text into the sets
of glyphs, words, and paragraphs that get "glued together" to comprise
a document.

Querying and looping aren't things it really has concepts for.

> Basically normal loop for a database report generator. In fact, I probably
> can use most report generator (including OpenOffice.org Base) to get the
> *content* I needed. The problems are that I cannot get in the *layout* I
> needed, and that some other report generators cannot produce output to all
> format I need (PDF, HTML, editable MS Word).

Getting all of those forms *is* a pretty high "bar" to set.  I'd
observe that on MacOS, the general model that the platform has taken
has been to make it as convenient as possible to generate PDF output.
For all kinds of applications, there's really just the one form of
output, which simplifies things dramatically.

I understand why someone might ask for all formats to do all kinds of
things, but they'll have to accept that choosing to generate output in
all those forms is a mighty expensive endeavor since they are
conceptually such different forms.

>> Again, it's not amenable, by itself, to programming things like mail merge
>> or database access - you'd presumably want to write code in some other
>> language that generates DocBook XML/SGML as output.
>
> Ok, docbook will be something different: it is not a layout nor template,
> but more like structured content. So the procedure will be as below, right?
>  1. A script queries the database according the rules of the intended
> layout.
>  2. The script generate a docbook contain the data.
>  3. An XSL convert the docbook to intended XML or an intermediate XML
> according to intended layout.
>  4. Another converter convert the intermediate XML to final non-XML
> document.

XSL is one possibility, yes.  I have *far* more frequently used DSSSL,
myself, but XSL does seem to be the "modern way" to do remappings.

> There are several issues with using docbook this way:
>
>  1. The "intended layout" / template definition need to be broken into the
> rules for the docbook generator script and the XSL. This complicates
> changing the "intended layout" / template.
>  2. As MS Word .doc files are not XML, the docbook need to be converted to
> something else first. It seems the good candidate is to ODF (there is
> converter to RTF but there will be many issues with complex formatting).
>  3. Is there any tools, that given an ODF file, can automatically generate a
> XSL from docbook to that ODF layout? If not, that's mean I need to learn the
> ODF specification, and how to generate XML for complex formatting in ODF,
> and how to do it using XSL. This sounds to be huge endeavour, definitely
> sounds much more than scripting OpenOffice.org.

I think you're fairly nicely characterizing the problems that you'll
face in trying to "be all things at once."

Conceivably, generating ODF (which, as you suggest, could be quite a
task) could replace generating DocBook.

You may want to step back and present, to the stakeholders, that
trying to create editable highly-formatted reports will be mighty
costly, and point out that cutting down on the number of formats (e.g.
- I could see arguing for "only PDF") would be a Very Large Savings in
how much it costs them to have their desired report generation
infrastructure.
-- 
http://linuxfinances.info/info/linuxdistributions.html
Fred Allen  - "California is a fine place to live - if you happen to
be an orange."
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists