This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
[docbook] Re: Tables, braille and other stuff
- From: Dave Pawson <dpawson at nildram dot co dot uk>
- To: docbook at lists dot oasis-open dot org
- Cc: docbook-apps at lists dot oasis-open dot org
- Date: Mon, 28 Apr 2003 16:57:08 +0100
- Subject: [docbook] Re: Tables, braille and other stuff
- References: <5.2.0.9.2.20030425163629.00addc70@pop3.Nildram.co.uk><OFA4DC50A5.DFB02FF9-ON85256D13.004CF6D7@pok.ibm.com><5.2.0.9.2.20030425163629.00addc70@pop3.Nildram.co.uk>
At 09:51 28/04/2003 +0200, Yann Dirson wrote:
My idea is that the very notion of a table is completely
layout-oriented.
I'd agree. But try telling that to an accountant :-)
Thus it should only appear in the stylesheets
What we really need (IMHO at least) is, like it was progressively done
until now to get to current Docbook, to identify what we're trying to
do when we _think_ we need a table. Of course, that's not an easy
part, and I don't claim I've solved it. I've merely tried to think
about it, and, even then, not much :)
The VI approach is to linearise, then describe.
E.g.
<listitem (I'm in cell A5) ... content.
I.e. present as a series of items, each with metadata,
which assists in locating it in the original table.
That seems reasonable, until we can persuade the world that tables
are visual only :-)
Some of the uses of tables I can list off the top of my head are:
- database-like listing
Grouping (hi level)
Naming (in the hi level grouping)
- bidimensional (or multidimensional) arrays,
Why? Because that's how programming langs do it?
Is that sufficient reason?
Suggestion.
Ask the person next to you to describe the data in the table
you come across.
regards DaveP.
---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-unsubscribe at lists dot oasis-open dot org
For additional commands, e-mail: docbook-help at lists dot oasis-open dot org