I myself lean a little bit towards using DocBook for such an effort. Here are a couple of reasons I think it might be the right tool for the job:
1. As it was mentioned before, the multiple formats export option is extremely useful, as generally, I want to write content, and not necessarily spend time on formatting things. There certainly may come a time when we might need to spend time on formatting the whole book uniformly, but at least initially, I'd rather not worry too much about that. In my opinion, although the "semantic xhtml markup" seems like an easy way to start with, it wouldn't be as expressive and explicit as docbook about the elements in the content of the book (unless someone is willing to spend time to heavily customize CSS stylesheets, write utilities to parse this "custom" format, etc) 2. A couple of years ago, I used DocBook to draft the first couple of drafts of my thesis, and it worked fairly well. Later on, when things heated up, I was able to import this first draft into OpenOffice and do some of the fancier stuff with it (e.g. I was adding index terms which is also possible to do w/ docbook, but I was under time pressure) 3. Although there will be some things to learn in starting w/ DocBook, there are a couple of mitigating factors: * There is the "Simplified Docbook" ( http://www.docbook.org/schemas/simplified) which makes the learning curve a lot less steep. If we decide to get fancy later on, it can certainly be revised. * There are a number of GUI tools for editing DocBook and not even know what's under the covers : e.g. XMLMind (http://www.xmlmind.com/xmleditor/) is free for personal use. * A number of XML editors support DocBook out of the box : jEdit has xml completion based on the DTD, NetBeans has a DocBook module (thanks to Geertjan and his crew), I'm sure that Eclipse has something there as well. * (although I'm very suspicious of php apps) This docbook project that Hugo mentioned (http://doc-book.sourceforge.net/homepage/) that allows wiki-like editing of docbook books and chapters might be worth taking a look at to support "simplified" editing interface for a more distributed crowd. 4. Although this is a pie in the sky goal, if we somehow manage to round up a publisher (e.g. something other than Lulu.com) who might want to print the book for real (wishful thinking), I was under the impression that some publishers (e.g. OReilly) do support DocBook as an input format 5. I don't think it is just a matter of being able to export to PDF. My point is that for example, other tools (e.g. Confluence, XWiki, etc) supports exporting to PDF from it's pages, but other than the tool in question, nothing else could do the same. With DocBook there is a wide array of utilities (both open source and commercial) that can manipulate the raw docbook in a variety of useful ways. I am in the process of badgering all my contacts for advice on best practices on how to proceed with writing a distributed type of book. Geertjan responded to my question about writing a book on his blog ( http://blogs.sun.com/geertjan/entry/collaborative_writing_in_a_distributed) , and overall his suggestion is that writing a book with other developers should be run just like any other software development project (in terms of infrastructure - e.g. source control, tooling, etc). I've also sent inquiries to a couple of other people I know, who might be able to provide some advice on the subject, we'll see what comes out of that. I also trolled the web for some references on the subject, and here are a couple of interesting experiences on the subject (so, that's what Howard was referring to when he was saying that writing book involves a lot of dull work): http://www.xaprb.com/blog/2008/06/15/what-is-it-like-to-write-a-technical-book/ http://www.emergentchaos.com/archives/cat_writing_a_book.html Anyway, I guess my point in posting these two links are they give an idea of what it is to publish a book w/ a real publisher. I don't think that anyone thought pulling off a book would be easy, but my (naive) hope is that being able to spread stuff among a larger number of people will make it less of a drag (although it would remain a huge amount of work) and more fun (by collaborating w/ everyone else). From the articles above, I especially liked the advice of writing progressively more detailed outlines (far beyond the urge of starting to write sentences). I also liked some of the heuristics for better style. Cheers, Alex Kotchnev On Tue, Aug 26, 2008 at 3:18 PM, Carl Crowder <[EMAIL PROTECTED]>wrote: > I'd be keen to help out, whatever the format used to write it. > > I assume there would be an editor to order it once it's written? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
