[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: output as tables
From: |
John Darrington |
Subject: |
Re: RFC: output as tables |
Date: |
Thu, 5 Jun 2008 08:03:15 +0800 |
User-agent: |
Mutt/1.5.17+20080114 (2008-01-14) |
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