This is the mail archive of the docbook-tools-discuss@sources.redhat.com mailing list for the docbook-tools project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Where, what and how - The future of DocBook


You should have a look at <http://www.nwalsh.com/docbook/simple/index.html>.


If you want some inspiration for modularization, you should look at the way
XHTML is being modularized, <http://www.w3.org/TR/xhtml-modularization/>.

IMHO, the real trouble starts when you do the applications to support your
modular DTD. Norman Walsh' modular DSSSL and XSLT stylesheets
<http://www.nwalsh.com/docbook/dsssl/index.html> might be an inspiration. If
you find out how to implement this for an FrameMaker+SGML EDD, I'd very much
like to know!


kind regards,
Peter Ring

-----Original Message-----
From: Pfaffner, Peter [mailto:PP0099@entitec.de]
Sent: 5. december 2000 16:27
To: DocBook forum (E-mail 2)
Subject: RE: Where, what and how - The future of DocBook


Hi all,
I'm new to this discussion list and not sure, if this is the right way to
reply to a topic (sorry if I'm wrong).

Peter Toft brought up an interesting Question:
>>>Many companies don't accept DocBook - why?
>>>Can't we do better???

I'm responsible for all kinds of technical standards for 12 months now. One
of them is documentation. Actually I decided to switch from MsWord ;-) to
FrameMaker+SGML for Windows and have to choose/create a company-DTD. To make
a long story short, I decided not to use DocBook as delivered.

Why?
Well, at first, our writers are not used to SGML/XML at all, or native SGML
authoring tools (thats the reason for an expensive WYSIWYG tool like
FM+SGML). And it is essential for a broad acceptance of the paradigm change
to make the switch as smooth as possible. Try to replace the good old
typewriter of your grandpa by a computer, and you know what I am talking
about :-). Microsoft customers are used to menus, choices and WYSIWYG (and
I'm too in the meantime). I've worked with IBMs DCF/GML for almost 10 years
being tired to stare at tagged plaintext to figure out, how it might look in
print.
I installed the DocBook 3.0 EDD(DTD) for FrameMaker and tested it. To be
frank, the content model (take Element Para for example) is overwhelming.
The naming conventions for elements are not consistent, so that related
elements are not near to each other in the (alphabetically sorted) valid
element list. The mixture of elements for articles, reference pages and
books in one content model makes the whole thing sort of clumsy and I guess,
hard to maintain too.
Looking forward to DocBook 5.0 (XML?), it may get worse, because XML doesn't
support SGMLs Include/Exclude.

My personel recommendation is:
split the DocBook-Standard into smaller one's with a common subset of
elements and attributes. Wrap similar elements (all list types) in higher
level structures (for example "Lists"), which can be unwrapped by XSLT, if
necessary.

What I will do instead?
I'm going to write a new, simplified and heavily reduced XML-DTD (hey, what
are nights and weekends for ;-) based on DocBook V4.1 and IBMIDDOC trying to
be as  DocBook conformant as possible.

Suggestions and comments are appreciated.



-----Original Message-----
From: docbook-tools-discuss-owner@sources.redhat.com
[mailto:docbook-tools-discuss-owner@sources.redhat.com]On Behalf Of
Peter Toft
Sent: Monday, December 04, 2000 12:07 PM
To: docbook-tools-discuss@sourceware.cygnus.com
Subject: Where, what and how - The future of DocBook


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]