From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Ring To: "'Pfaffner, Peter'" , "DocBook forum (E-mail 2)" Subject: RE: Where, what and how - The future of DocBook Date: Wed, 27 Dec 2000 06:36:00 -0000 Message-id: X-SW-Source: 2000/msg00410.html 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Ring To: "'Pfaffner, Peter'" , "DocBook forum (E-mail 2)" Subject: RE: Where, what and how - The future of DocBook Date: Tue, 05 Dec 2000 07:45:00 -0000 Message-ID: X-SW-Source: 2000-q4/msg00051.html Message-ID: <20001205074500.SMze5a0HnMcMMKB4wcaviL0saguv9AVHDqnDbVseX0I@z> 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