On Sat, 2004-09-18 at 05:24, Dave Pawson wrote: > What rationale is there for remaining with the SGML toolchain? Ironically, the same reason that businesses worldwide stick with old-but-working systems, where working == we hacked it to work well enough to ship. For the time to produce Enterprise Linux 4, we didn't have enough cycles to do the R&D ourselves and start writing our guides for the next release. There are significant cross-team constraints, such as having percentages of guides string and code frozen for the translation team to work on. Frankly, it was pretty daunting to imagine doing the XML toolchain all ourselves. At the time that we had to choose go/no-go on switching to XML, there were too many problems in the community tools (xmlto PDF conversion being a big one, iirc), so we had to stick with SGML. Once we started working in SGML for the production release, we had to stick with it all the way through until release. However, and here is the double-good news: because of all the good work we are doing here proving the capabilities and readiness of the latest DocBook using XML, those of us who are writing new guides (i.e., no legacy SGML) _and_ who are not being translated will get to choose to use a parallel XML toolchain based on the FDP tools for the Enterprise Linux 4 release ... well, probably nearly exactly the FDP tools with our XSL or DSSSL (again, prepared to use DSSSL just in case we can't pull the trigger on XSL in time). That means I'm writing 100% in XML, as soon as I take the few hours to convert my existing work from SGML. :-) - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
