<br><br><div class="gmail_quote">Bryan Kadzban wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Depending on the language (and libraries available), it may even be<br>

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