[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: output as tables

From: Ben Pfaff
Subject: Re: RFC: output as tables
Date: Tue, 03 Jun 2008 20:10:28 -0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

John Darrington <address@hidden> writes:

> 1.  One thing the current system can't do is footnotes.  The system
> you describe could do this if it allows a metadatum to be attached to
> an individual cell.  The sub/superscript style should of course be
> handled by the output engine.
> 2.  More complex tables will need some way of having headings which
> span more than one row/column.  There are two ways that I can see of
> doing this:

I agree that these are desirable features for presentational

But this response leads me to think that I've failed to
communicate.  Partly, I think, it's vocabulary.  I'm using the
word "table" in two very different senses:

        1. A table used for presentation to a human user.  These
           are the tables in PSPP's src/output directory, for

        2. A table in the relational database sense.

To reduce the confusion, I will henceforth only use the term
"table" in sense #1.  Tables in sense #2 I will call "relations".
My entire original message with subject "RFC: output as tables"
was actually about relations.

I think that another way that I didn't make myself clear is that
I only presented a fraction of my proposal, even though I have
more in mind.  Let me step back, then, and outline the whole
solution that I've been trying to design.  Here's a high-level
view of what we have now:

        1. Statistical procedure analyzes data. 

        2. Statistical procedure creates table.

        3. Output subsystem renders table on each output device.

Here's what I'm proposing as a replacement for the equivalent

        1. Statistical procedure analyzes data.

        2. Statistical procedure outputs relations that
           semantically express statistical output.

        3. Intermediate language transforms relations into

        4. Output subsystem renders table on each output device.

(Based on our goals, we also want to support two additional
cases: "semantic output", where step 3 becomes "write output as
CSV or XML (or whatever)" without any transformation into tables;
and "interactive output", where the user gets to interactively
influence the rendering in step 4 and possibly the transformation
in step 3.)

The message that I sent out only talked about step 2.  We haven't
discussed steps 3 or 4 yet, which is where your two suggestions
above would fit in.

> 3.  In a few obscure cases, the number of columns in a table is
> unknown rather late in the procedure (ie after all the data have been
> read).   So I'd rather that the new system didn't require the
> dimensions of the table to be declared up front.

My tentative plan would be that relations be implemented in terms
of casereaders and casewriters, since they are similar concepts
and we already have a nice collection of variants.  To handle
this case, you could use a datasheet, which has good support for
dynamically inserting and deleting columns (and rows), and then
convert it to a casereader with datasheet_make_reader when you're
done with it.
Ben Pfaff

reply via email to

[Prev in Thread] Current Thread [Next in Thread]