A Book Log
Here are other people I know who keep booklogs. I'm defining this pretty narrowly so that I don't end up reproducing my entire list of bookmarks.
For some years now, I've had a site with reviews of recommended SF and fantasy (which is still linked from the archive), but I'd gotten lazy about updating it -- I had such a big backlog of recommended books that it was just intimidating. Plus, updating the site was rather tedious, inasmuch as it involved constantly mucking about with HTML. So, when everyone started jumping onto the booklog bandwagon, I decided I'd give it a whirl, too.
I know that absolutely nobody cares about the technical details here, but I want to talk about them. I think I'll do this in a fake Q&A format.
Q: So, what blogging system do you use for creating Weasel Words?
A:I'm not using any pre-made system; I decided to roll my own.
Q:That seems like a lot of work. Why not just use Movable Type?
A:Two reasons, really. The first is that Movable Type doesn't work from Lynx (it needs JavaScript), which I use a lot. The second is that I don't trust my content to non-standard storage formats (MT uses Berkeley DB or MySQL). I've had my book database around for a long time, and as I've moved from server to server, I've had to change both the format that I stored the data in, and the code I used to access the data.
At different times, my book database has been stored in GDBM files, NDBM files, tab-delimited text, Postgres, Access, and SQL Server. It's a bit of a pain to have to keep converting data from one format to another as the capabilities of my hosting server change -- and it's nearly as much of a pain to have to rewrite the code to extract the data. Thankfully, there's now a standard, cross-platform way to store structured data: XML. Having come to the XML conclusion with my book database, I wasn't about to regress with my booklog.
Q:So you're using XML for your booklog? Tell us about how that works.
A:Sure thing. All of my booklog entries are stored in an XML file, with a structure that holds their ID (used for permalinks and contents), date, entry title (if any), and information about all the books reviewed in that entry.
When I want to add a new entry, I execute a Java Python program. It fills out a template with all the data it can glean automatically (a new ID, the date), then brings it into an editor where I can fill in the rest of the entry. When I'm done, it validates my entry as XML (which requires me to effectively write XHTML; more on that later), adds it to the booklog XML file, and then publishes it.
Q:What does publishing entail?
A:Right now, there are four steps to publishing: Generating the appropriate monthly page, generating the front page (which is essentially the same page with a different URL), generating the RSS, and generating the monthly archive index. To do this, it applies XSLT transformations to the XML file, and renders the result as HTML 4.01 Strict.
You'll note that I said "right now" just above. The neat thing about this publishing system is that it gives me enormous flexibility to create alternate forms of output. When I have the time and motivation, I intend to add an archive with the entries sorted by author. (And, I add much later, this actually happened, as well as tags!)
Q:That all sounds cool. But, if I may ask, why HTML 4.01? With such an XML-oriented publishing framework, it seems like you'd want to use XHTML, instead.
A:Actually, it's because of the XML framework that I don't want to use XHTML. There are a couple of minor reasons not to use XHTML on the Web right now. I don't consider these show stoppers, but the thing is, there are absolutely no offsetting benefits to using XHTML. It doesn't provide better rendering, it doesn't provide new capabilities, it's not especially more flexible. As I write this, serving XHTML on the Web is pretty pointless.
That's not to say that XHTML itself is pointless. Quite the opposite, actually. There are an increasing number of tools out there that can do powerful things with XML documents. If you're writing HTML content that you expect to be long-lived right now, it makes sense to write it in XHTML. Which I am, actually: because I'm storing all my booklog entries in an XML file, their content need to be well-formed XHTML. Because of the output flexibility that XSLT gives me, though, I can output my pages as perfectly-formed HTML 4.01, even though the stored data is in XHTML format. And, when Web browsers support XHTML better, I can flip a switch and output perfectly formed XHTML 1.0 just as easily.