Re: RFC: output as tables

[John Darrington]

On Tue, Jun 03, 2008 at 10:24:04PM -0700, Ben Pfaff wrote:

     We will need a way to map from relations to tables, yes.  My
     tentative approach to this is that each statistical procedure
     would be accompanied by a little bit of code to do this
     transformation.  This code would probably not be written in C.
     Its duties would be:
     
             1. Use relational queries to join relations as necessary,
                producing a relation that is isomorphic to what the
                presentational table will show.  (The language for
                these queries might be SQL, but that is possibly too
                heavy-weight.)
     
             2. Designate columns in the resulting relation to be
                represented as rows or columns or layers, etc., in the
                presentational table.  This is where the Polaris paper
                I cited earlier comes in, or where the Wilkinson work
                comes in.
     
                (In a GUI, the user could adjust these choices
                interactively, in the fashion of a pivot table.)
     
             3. Provide default styles: column and row labels, lines
                between cells, colors, and so on.  (Think of what
                cascading style sheets makes possible here.)
     
                (In a GUI, the user could also adjust these choices
                interactively.)
     
     If done properly, it should be a rather small amount of code per
     procedure, easier to write than the corresponding formatting code
     we have now, and much more flexible.
     
I think that if the system is designed carefully, then this "code"
need be merely a bunch of metadata.  In other words, put all the code
in the output engine, and make it flexible enough to be controlled by
some variables which are contained within or associated with the
relation.  Encouraging procedure authors to write their own programs
for controlling the display, I think would be a bad thing.

The output engine should be intelligent enough to use a default set of
style data, which can map a relation into a table in a sensible way if
no other data is given.  With a bit of luck, many procedures will need
relatively little extra data to make the output aesthetically
pleasing.

J'



-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature