Re: [docbook-comment] "chapter" in table

Hello Bob,

Thank for your answer.

There is an example at page 68 / 173 of http://www.arianespace.com/wp-content/uploads/2018/04/Mua-6_Issue-1_Revision-0_March-2018.pdf

Networks of pipes or cables in industrial plants are also presented as table :

* columns refer to temperature, pressure, flow...

* lines correspond end to end pipes

* "chapters" are groups of pipe lines with the same fluids (air, water, oil...)

1. May be modelizing the information as a table is not the best way in this case : a segmentedlist would be more appropriate and the stylesheet would make the rendering as a table, grouping lines under a "common title" based on the value of one element seg.

2. In the example, building the "chapter" "Launch preparation nominal sequence" by reusing some fragments would involve 5 elements xi:include, one for each line.

I just don't see how someone could ensure reusing the 5 of them as a whole (idiot proof).

Regards,

Florimond

Le mardi 26 mars 2019 Ã 17:05:16 UTC+1, Bob Stayton <bobs@sagehill.net> a Ãcrit :

Hello Florimond,

I would be interested to see an example of such a table and how you would like to see it rendered to determine how it might be accomplished with the existing elements before trying to alter the table model that DocBook uses.

DocBook tables are based on the standard OASIS XML Exchange Table Model (which was derived from the older standard CALS table model). That standard is described here: https://www.oasis-open.org/specs/tablemodels.php. DITA also uses the OASIS Exchange Table Model.

I can tell you that the DocBook Technical Committee would need to be thoroughly convinced of the need for this change in order to break from this standard table model. Most people edit complex tables using table display software such as Oxygen Author, XMLMind, or XMetal because it is difficult to mentally interpret the complex XML markup for tables. Those software products are all written using the same standard OASIS Exchange Table Model, so DocBook tables would no longer work in those products if DocBook used a different model. Breaking such compatibility would hinder the use of DocBook.

The DocBook Technical Committee remains open to suggestions for improving DocBook. It's just that this change would have far reaching implications, so it would be looked at very carefully.

If you want a wider audience for discussing your idea, I suggest you post it on the "docbook" mailing list on OASIS. That mailing list reaches DocBook users interested in the DocBook schemas. You can subscribe by entering your email address at this URL: https://www.oasis-open.org/mlmanage/

Bob Stayton

Sagehill Enterprises
bobs@sagehill.net

On 3/24/2019 1:01 PM, Alemps Florimond wrote:

Hello,

In engineering world, there are some tables :
* where columns are defined for the whole table (item #, designation, power, weight, voltage...).
* some lines related to the same topic (Elevator #1, conveyor #2 ...) are grouped.

To achieve ths, there a different options :
1. To repeat the name of the topic on each line
2. To create a new table for each topic

I find those options not really elegant (identical first cells of each row, or management of headers and columns/colspec for each tables).
Instead of :
db.cals.table
    * tgroup
        * colspec
        * thead
        * tbody
        * tfoot
This kind of "schema" could help answer such a requirement :
db.cals.table
  * colspec
  * thead
  * tfoot
  * tgroup
      * thead
      * tbody
      * tfoot
 
There a is a common header for the whole table, managed like today when published (repeated when changing pages as an example).
A tgroup corresponding to a given topic embed a thead and containing the row of the "title" (with an adequate colspan) enables the reuse of a consistent set of rows.

What do you think ?
Florimond

docbook-comment message