Re: [docbook] Ruminations on the future of DocBook

[ed nixon <ed.nixon@LynnParkPlace.org>]

Dave Pawson wrote:

> At 11:31 31/05/2003 -0400, ed nixon wrote:
>
>> For example, what about a mapping of DocBook elements to XHTML 
>> elements? As a first approximation of a "core" set? It would likely 
>> be many-to-one in most cases. DocBook is richer with respect to 
>> XHTML, but that DocBook subset, call it a *new* SDocBook might be a 
>> good starting point to look at modularization with respect to other, 
>> more specific, more rich
>> requirements for other forms of technical documentation.
>
>
> And quite possibly it would meet the needs of ??? 70% of docbook users?
> I.e. all those who mark up in docbook and present in (X)HTML?

I'm reading Edward Tufte's new essay, "The Cognitive Style of 
Powerpoint" (You can buy it for $7 from his web site, 
http://www.edwardtufte.com; it's excellent as are all his other books of 
design and display of data.)

In the essay he is making points about the inadequacy and even dangers 
of PPT "rhetoric": slides, bullets, phrases and hierarchies for 
adequately explaining complicated situations and processes. For example, 
he critiques the slide presentations assessing tile damage to Columbia 
that were done by Boeing engineers for NASA officials in the decision 
process about whether to do further investigation and/or allow the ship 
to land.

He says, "People have communicated about complex matters for centuries 
without hierarchical bullet lists. Richard Feynman wrote about much of 
physics -- mechanics, optics, thermodynamics, quantum behavior -- in a 
600-page book with *only two levels*: chapters and headings within 
chapters."

I guess I'm trying to make an analogous point about comparative semantic 
markup. To answer your question, Dave: Yes, the 70+% of DocBook users, 
but not necessarily constrained to web output. Or, at least, when we 
remember that there can be print-oriented CSS, as well as FO/PDF, output 
that is not just published to electronic channels.

                   ...edN