On Saturday 01 March 2008 22:51:30 Dave Wheeler wrote: > On Sat, Mar 1, 2008 at 10:15 AM, George Makrydakis <[EMAIL PROTECTED]> 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!) .
Complexity at times is necessary for making things scale. > 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. You will end up requiring much more than a parser in anycase. Because parsing is one of the problems, not all of them, and not even the most important one. If you want to go the XSLT way of doing things, a simpler solution would be to write it in Haskell, which is a language dedicated to functional programming, unlike the semifunctionality of XSLT. Not to mention the difference in many, many things. And actually, if you do it with C++ you will not end up with templates "that look just like XSLT" unless you introduce code bloat templates and do a lot of hardcoding for LFS, limiting portability of the tool to other projects, but that is another case. Implementations vary. What you could do, would have to implement the features in a native to nALFS mode. It will keep happy most of the people and gain momentum. As you imply below. On a brighter note, a multicomponent system allows user interaction. Things should vary from the very simple to the very complicated, according to the needs. In my eyes, not all people have the same needs. Those who have simple needs, can even compile a makefile ala Christoph Devine & Jeremy Utley mode. > 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? Nobody said that you could not expand nALFS. An even simpler solution even would be to just use what the LSB guys have and build your own RPM distribution from scratch without problems. You could rewrite the book into LSB - compatible mode and feed it to nALFS without touching nALFS that much. > If that were the case, then the > book would also be your automation scripts! Enjoy. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
