On Mon, Sep 01, 2008 at 01:57:10PM -0400, William Immendorf wrote: > > > Bruce Dubbs wrote: > > >> the biggest > >> barrier I think we have, is the fact that xmllint and xsltproc couldn't > >> handle RNG documents correctly. > > >To me this is a show stopper. We need those or the equivalent programs to > >generate the book in its various forms, wget-list, etc. > > Then try both Saxon and Sun MSV (Multi-Schema XML Validator). However, they > need Java, so be preapred for that. >
So far, I've managed without java, and I see absolutely zero reason to install it on my machines. At the moment, you haven't bothered to reply to my questions and comments. I have noted that the dynamic book will be able to provide different package managers for different users, but I'm still in the "I came here because I loathe the overhead of package managers" camp. That still leaves the majority of my post unanswered. To paraphrase (bearing in mind that I mostly ignored the noise about package management and dynamic books earlier this year, waiting for something that was in a fit state to comment on): Who the hell are you to say "this is the way forward" without providing argued reasons ? (Valid answers might include "Gerard's nominee", or perhaps you have some existing position in the LFS projects of which I'm unaware.) If you merely intend to _propose_ a change, you _have_to_ provide better justification for it. What changes does it mean for individual editors ? Why is adding packages such as php to the LFS webserver (when we appear to be extremely slow to update for known vulnerabilities) a good idea ? > >> After spending all this effort, just to get us to the same state as we're > >> in > >> currently (i.e. can validate and render the book sources), what, > >> definitively > >> do we gain? > > >I asked this question yesterday too. Until that is answered satisfactorily, > >I > >don't think the current build method will be changed. As of right now, I > >just > >don't see any significant benefit, but a lot of effort. > > The advantage is that we can create elements that we want. Rember, XML is > eXtendible. Like a code element that replases the tired old screen and > userinput combo. > We can also remove useless elements. So, how does that help ? When I've made edits, I've never felt the need for an element that isn't available. Certainly, I often think there are too many elements, but that is because some of the people here care more deeply than I do about some of the nuances of how the book is rendered - so, the elements I think are not particularly important are indeed useful and ought to be retained. You refer to the "tired old screen and userinput combo" - where is the problem with it ? Maybe you are caught up in the "web 2.0" buzzphrases ? At the moment, I don't have a killfile. People _discussing_ the development of the book have a right to be heard, even if I dislike what they say. But you apparently come out of nowhere with a statement of "Что делать"(1) and no explanations of why you think this will improve anything. You are trying my patience. ĸen 1. - the original title, in Russian of "What Is To Be Done ?" by Lenin - at least according to wikipedia - I've dropped the question mark because you aren't asking, you are proclaiming. -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
