Planning an overall direction for LFS

Dave Wheeler dwwheeler at
Fri Feb 29 12:51:15 PST 2008

Bryan Kadzban wrote:

> Depending on the language (and libraries available), it may even be
> possible to generate the web stuff automatically from the XML sources.
> It would depend in part on what tagging we can do (although I bet that
> an XML-Schema or Relax-NG schema for DocBook would be better suited for
> it, as we can then group pieces based on our own namespace and schema).
> If we can figure out a way to add our own tags to each current page,
> saying what module it belongs to (or however it would work), that'd make
> it fairly easy.
> Actually, at that point, it may even be possible to generate the HTML
> directly from the DocBook using some kind of XSLT.  I'd be more
> comfortable if it was done in a traditional language, but that's just
> because I don't grok XSLT much at all.  ;-)
> (And if that kind of thing is workable, the "barrier to entry" wouldn't
> have to be a whole lot higher than it is now.  Writing the server side
> code could be done once; the XML would still drive everything.  There
> may be a few occasional maintenance issues with the scripts, but the
> main book development could probably still happen in XML.)

For generating dynamic content, docbook xml could only be matched by keeping
it in a relational database.  This is a case where xml would be better than
a db (and php has lots of nice libraries for manipulating xml - not sure
about python! :) )

I haven't grokked xslt much either up until quite recently.  I've been
working on a way to convert the docbook format to a working ALFS profile,
and have been taking two approaches.  One is a C++ approach (complete with
my own lightweight (non-validating) xml parser) - this aproach is nearly
complete, but the code is bloated and I'm not sure it's a workable tool.
The other is xslt - believe me, when you've written enough manipulations of
XML in C++, xslt starts looking easy and even desirable.  After I read
Gerard's original post about LFS not being a book, I started tinkering
around with that concept and yesterday I wrote the attached xslt
stylesheet.  It will take the latest dev docbook (I don't think this will
work with stable - some of the necessary tags have been added in dev since
the last stable release) and convert it to an ALFS profile (the second file
is the converted ALFS profile).  If you load this profile in nALFS with
comments on (--display-comments), you'll see both the commands for nALFS to
carry out, as well as comments that contain the descriptive/educational
content above those commands. (Don't try to run this profile - this is just
POC & won't work as-is!)

Something I've thought of again and again over the last couple of months
during this process, and hopefully something the ALFS folks will consider
(and something I'd like to help with)....Instead of converting docbook
documents to ALFS profiles, why not just change nALFS to work directly from
the docbook format?  Then the documentation drives everything - not just the
html and pdfs, but also automation and testing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lfs2alfs.xsl
Type: text/xml
Size: 2242 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LFS.xml.bz2
Type: application/x-bzip2
Size: 100222 bytes
Desc: not available
URL: <>

More information about the lfs-dev mailing list