What if the book wasn't a book anymore
Dave Wheeler
dwwheeler at gmail.com
Sat Mar 1 13:51:30 MST 2008
On Sat, Mar 1, 2008 at 10:15 AM, George Makrydakis <george at obsethryl.eu> wrote:
> This means that the entire design should focus on the fact that you are
> dealing with a database by itself, not a book.
Seems like a much simpler solution would be to transform the book into
something else an automated tool can use. Like nALFS. See the
attached for a start on an XSLT approach to this - it will convert the
lastest SVN version of the LFS docbook sources into a profile - and if
you start nALFS with the --display-comments, you'll see the text of
the book as comments separate from the commands - isn't this what
Gerard was picturing at the start of all these posts? (WARNING -
don't try to run the profile if you do load it in nALFS - I promise
this POC it won't build a system successfully!) . On a further note,
I've also mostly implemented this in C++, with my own lightweight XML
processor - and in the end I'm going to end up with C++ templates that
look just like XSLT, so might as well try the XSLT approach before
carrying the C++ approach any further.
And a thought for all to consider (and something I'm probably going to
work on regardless the response here): During the course of coding
this conversion tool, I've come to ask myself many times - wouldn't
this be much easier if nALFS could just act directly on the docbook
XML instead of using it's own DTD? If that were the case, then the
book would also be your automation scripts!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lfs2alfs.xsl
Type: text/xml
Size: 2241 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/lfs-dev/attachments/20080301/db337cbc/attachment.xml
More information about the lfs-dev
mailing list