Re: [Gnue-dev] GNUe Reports Output Markup

[Derek Neighbors]

> After looking at the feedback on using XML namespaces in Reports, I've
> decided that's the route I'm going to take.  Now that I know *how*
> output tags will be represented, I now need to know *what* these tags
> will be :)

The only bad decisons are those not made right... :)

> that this is for the *Official* GNue Reporting language and DOES NOT
> include such things as preprinted forms and mailmerging. I plan to do

I think we should handle these separately as well.  Since they are more 
specialized they should probably be addressed after we have a civil model 
for normal reporting. :)

> 1. The report definition shouldn't contain references to page sizes,
>    etc, for a few reasons:
>       a) Paper sizes vary by locale (e.g., US Letter vs A4)
>       b) For outputs such as html, csv, et al, papersize is
>          irrelevant.
> 
>    We might, however, provide *hints* (e.g., this report looks
>    best in a landscape format, etc)

I see this as something the reports 'client' chooses so is irrelevant to 
the spec.  

> 2. I'm thinking in terms of a "logical" formatting markup, similar
>    to HTML, DocBook, or TeX, as opposed to an "absolute" formatting
>    markup (Postscript). I say this as doing such a format will make
>    the various final outputs (html, csv, pdf, etc) easier to create
>    from the same source stream.
> 
>    In other words, I don't think the report should denote <draw
>    label at position x=100, y=100.>

I agree,, that would be addressed in a different output type.

> 3. Some "final" formats we will want to support are:
>      * PS/PDF
>      * HTML
>      * RTF
>      * CSV
>      * TeX/LaTeX
>      * ???
I would say staroffice/excel/word (in native xml format)  Mind you Im not 
saying MAIL MERGE, but rather actually transform into these formats.  I 
wont elaborate too much but Excel's format is very interesting in this 
area as its SOOO much better than exporting to csv then opening in excel.
 
> >      (A lot of other formats can be created from these basic formats.
>       e.g., once we have PS format, then ghostscript could convert to
>       oddball formats such as Epson ESC/P, HP-PCL, ... )
> 
>      Odds are, we will initially use an XSLT script to convert from
>      our "output" xml to these "final" formats.

Agree.

> 4. I would like to see a generic report "skin", or template, that
>    can be applied in between our "output xml" stream and the
>    "final format" (possibly applied by the XSLT engine) that applies
>    site-specific conventions (e.g., paper size, logos, standard header
>    styles, etc)  I touched on this in an earlier email.

Here we might be able to use 'entities' in the .xsl files or use multiple 
.xsl files.  I need to read up on something first, before I give a formal 
reply.  I do hoewever agree with the concept.

 
> Here are some tags that Derek suggested some other reporting tool uses.
> This doesn't mean we have to use them the same way, or use them at all.

These were blatantly ripped from QuickReports (Which i do not like nor 
endorse, but we needed somethign from which to start)  Many of the 
concepts I dont like but it gave an idea of how someone else is doing it.  
Btami suggested we look at datavision as well.  WE should garner 
information from as many packages as we can prop and free.

> Also, I'm not sure of the need for "expressions" in the output format.
> There will be "formulas" and "triggers" in the report definition file,
> but these will be resolved to actual values prior to being placed in the
> output stream.

I tend to agree, the only exception I can think of is in native excel 
format you can carry expressions as well. which is interesting, but thats 
another conversation and not a necessity.

-Derek