Re: [Gnue-dev] GNUe Reports and xmlns, oh my!

[Jason Cater]

When I read the first email, I was thinking to myself, "What is this crazy
Brit talking about?"

Then, with the arrival of your second email,  I realized this parallels
one of my wishlist items: "skinnable" (or templated) reports. I would say
that 80-90% of all my reports at NCS look identical.  I'd like to create a
few "formatting templates" that describe the physical layout of reports
(letter size; NCS logo; header information with page number, date, title
locations; et al)

To apply this to GNUe, consider all the GNUe Financials reports.  I would
like to see the actual report definitions define the logical
organization/calculation/sorting of data and have one or two "templates",
or formatting layouts, that define my preferred margins (1"), preferred
paper size (letter instead of A4), preferred font (Helvetica), and that I
want my logo at the upper left corner, the date and username in the upper
right corner, and the page number in the lower right corner.  I also want
every two lines of "table-style" detail bands to use 90% shading and no
borders. Oh, and my accounting department prefers negative numbers to be
formatted as "(999.99)" and not "999.99CR". 

I could define this for my company and not have to touch any of the actual
Financial Reports (unless I actually want to modify the underlying
reporting model.)

I'm not sure if this is exactly what you were describing (I need to
re-read your stuff as I am in a hurry right now), but in some ways seems
to parallel it.

> Of course, I have probably outlined the design of a Mercedes Benz 
> here, when all you wanted was a soapbox go-cart...

I want to create a jet-propelled army tank with leather interior that can
crush the Mercedes Benz and go places the soapbox go-cart couldn't dream
of :) 

 Well, at this point, I'd actually be happy with any of the three :)

-- Jason

On Thu, 21 Mar 2002 21:36:17 +0000
"Peter Sullivan" <address@hidden> wrote:

> On Thu, 21 Mar 2002 07:09:50 Peter Sullivan wrote:
> > Hi Jason. Believe or not, I was actually thinking about this on the
bus > > home 
> > from work last night. (I'm not normally the sort of person who tries
to > > design 
> > XML schemas in his head for fun, honest, I'd just had that kind of 
> > day...) 
> > I'll give this some more detailed thought today, and post to the list 
> > hopefully tonight.
> 
> OK, I have sorted my ideas out and come up with the following. 
> The first big disclaimer is that I am no XML expert, however.
> 
> Proposal
> ========
> 
> A GNUe report would be built up from two XML documents - 
> the GNUe Report Format and the GNUe Report Data.
> 
> 1) GNUe Report Format XML
> -------------------------
> 
> In the GNUe Report Format document, the <field> tag becomes a 
> proper container, which can contain either a field name, a 
> formula involving a field name, an absolute formula, or absolute 
> text. 
> 
> The attributes of the tag give information about the formatting - 
> both in terms of "cosmetic" formatting such as font and alignment 
> and "semantic" formatting such as sorting and subtotals.
> 
> ----------------------------------------------------------------------
> 
> <report>
> <band type="rbTitle">
>    <field ul="yes" font="24pt" align="centre">='MY ZIP CODE 
>                                                        REPORT'</quote>
> </band>
> <band type="rbDetail">
>    <field>='Item'</field>
>    <field>%State%</field>
>    <field font="12pt" count="yes">%City%</field>
>    <field title="Thing" sort="up">=left(%City%,4)</field>
>    <field format="#,###,###" sum="yes" 
> align="right">%Population%</field>
> </band>
> 
> </report>
> 
> ----------------------------------------------------------------------
> 
> The use of = as a formula marker is based on everyone's favourite 
> free and non-free spreadsheets, but could be any character that 
> is forbidden in a field name. Also, I'm not sure if we need a field 
> name delimiter, or what a sensible character would be for this - I 
> suspect % has too many special meannigs, not least in SQL92, to 
> be a wise choice.
> 
> 2. GNUe Report Data format
> --------------------------
> 
> The GNUe Report Data would be a simple XML document containing all 
> the data for the report. For illustration purposes, I have hi-jacked 
> the normal HTML table tags here, which may or may not be wise:
> 
> ----------------------------------------------------------------------
> 
> <data source="mysource" rows="4"> 
>    <-- rows not strictly neccessary, but may make coding easier -->
> <tr>
>    <th>State</th>
>    <th>City</th>
>    <th>Population</th>
> </tr>
> <tr>
>    <td>AK</td>
>    <td>Anchorage</td>
>    <td>100000</td>
> </tr>
> <tr>
>    <td>AK</td>
>    <td>Juneau</td>
>    <td>10000</td>
> </tr>
> <tr>
>    <td>AL</td>
>    <td>Montgomery</td>
>    <td>50000</td>
> </tr>
> <tr>
>    <td>AL</td>
>    <td>Birmingham</td>
>    <td>1000000</td>
> </tr>
> </data>
> 
> ----------------------------------------------------------------------
> 
> 3. Producing reports from these files 
> -------------------------------------
> 
> The GNUe Reports 'engine' would transform these two documents into 
> a composite XML document, processing and discarding all the 
> "semantic" attributes, and leaving the formatting attributes: 
> 
> ----------------------------------------------------------------------
> 
> <report>
> <band type="rbTitle">
>    <field ul="yes" font="24pt" align="centre">MY ZIP CODE 
>                                                        REPORT</quote>
> </band>
> 
> <band type="rbTableHeader">
>       <field>Item</field>
>       <field>State</field>
>       <field font="12pt">City</field>
>       <field>Thing</field>
>       <field align="right">Population</field>
> </band>
>    
> <band type="rbDetail">
>    <bandrow>
>       <field>Item</field>
>       <field>AK</field>
>       <field font="12pt">Anchorage</field>
>       <field>Anch</field>
>       <field align="right">100,000</field>
>    </bandrow>
>    <bandrow>
>       <field>Item</field>
>       <field>AL</field>
>       <field font="12pt">Birmingham</field>
>       <field>Birm</field>
>       <field align="right">1,000,000</field>
>    </bandrow>
>    <bandrow>
>       <field>Item</field>
>       <field>AK</field>
>       <field font="12pt">Juneau</field>
>       <field>June</field>
>       <field align="right">10,000</field>
>    </bandrow>
>    <bandrow>
>       <field>Item</field>
>       <field>AL</field>
>       <field font="12pt">Montgomery</field>
>       <field>Thing</field>
>       <field align="right">50,000</field>
>    </bandrow>
> </band>
> 
> <band type="rbTableFooter">
>       <field></field>
>       <field>Count:</field>
>       <field>4</field>
>       <field>Sum:</field>
>       <field align="right">1,160,000</field>
> </band>
> 
> </report>
> 
> ----------------------------------------------------------------------
> 
> This would then need to be transformed again by the "Format Engine", 
> into a format suitable for the target presentation mechanism 
> (HTML, ps, pdf, ASCII text, etc). The Format Engine would be 
> responsible for degenerating unsupported format attributes for the 
> target presentation mechanism into something vaguely usuable (probably
> not a big job, except for ASCII) and also handling things like page 
> breaks for formats where this was a valid concept :
> 
> ----------------------------------------------------------------------
> 
>          MY ZIP CODE REPORT
>          ------------------
> 
> Item State City       Thing Population 
> ---- ----- ----       ----- ----------
> Item AK    Anchorage  Anch     100,000
> Item AL    Birmingham Birm   1,000,000
> Item AK    Juneau     June      10,000
> Item AL    Montgomery Mont      50,000
> ---- ----- ---------- ----- ----------
>      Count:         4 Sum:   1,160,000
> 
> ---------------------------------------------------------------------
> 
> This idea is extensible, in that you can start with a fairly small 
> set of supported attributes for the <field> tag, and extend them as 
> you see fit.
> 
> The benefit of this double-transformation approach is that you can 
> completely abstract the report format from the data - which means that 
> report formats become reusable.
> 
> At a guess, I suspect you are looking at some custom python for the 
> first transformation (unless XSLT is a lot cleverer than I am aware of),
> but the second transformation should be a fairly simply XSLT stylesheet.
> 
> Of course, I have probably outlined the design of a Mercedes Benz 
> here, when all you wanted was a soapbox go-cart...
> 
> -- 
> Peter Sullivan <address@hidden>
> 
> _______________________________________________
> Gnue-dev mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue-dev