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

[Peter Sullivan]

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>