Re: RFC: output as tables

[Ben Pfaff]

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
tables.

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
           example.

        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
case:

        1. Statistical procedure analyzes data.

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

        3. Intermediate language transforms relations into
           tables.

        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 
http://benpfaff.org