What's gone before

So what's happened so far? First the idea for pbwdm occurred to me (see History). Then I heard about Google's Summer of Code program and wrote up an application for the project (the proposal). One of the first hurtles was that, due to a mix up on Google's end, it took a long while to confirm that I was, in fact, approved. This delay caused some lost time so I had to modify the deliverables due to having about half the time promised in the program.

The first hurtle regarding actually programming was discovering that Paperboy was not quite ready for production at the level that pbwdm requires (see Non-emulated Paperboy, further down). To deal with this I created XML::Paperboy::PurePerl to be a pure Perl emulation of paperboy, and started working heavily with the Paperboy RSS Team to push for getting v1.0.0 published so work on making Paperboy library driven can begin.

The first major task was to design a sort of ontology (see also Mark Heller's Virtual World Ontology thesis)—by which I mean design a set of ideas and how they're related—for describing websites. First I came up with an object oriented model, which I then translated into XML. By using XML instead of Perl objects I vastly reduced the amount of code in the project, removed the requirement that users need to know Perl to operate titania, and increased startup time performance. An account of the ideas I came up with are described on the <pbwdm:site> description page.

The second task at hand was to create the new XSLT functions titania will need. On the one hand I wanted to make sure users can do everything they want to do, on the other hand I wanted to keep the number of functions added to a minimum. The functions I came up with are documented in the POD for XML::Paperboy::WDM::XSLTFunc (that is, go to your shell and type perldoc .../pbwdm/src/lib/XML/Paperboy/WDM/XSLTFunc.pm to read it, replacing the ellipses with the appropriate path). I'm holding off on including those definitions on the website because, as you can see, there are a number of functions for different approaches to dealing with combining content from different databases, many of which cause segfaults (see Embedded XSLT, below). Some of those segfaults are repaired in a newer version of the XML::LibXSLT module (1.58_1 instead of the 1.58 I have installed), but some might be actual bugs with the approach. In any case, the essential functions like var() do work as advertised so unless you're doing embedded XSLT stuff, you should be fine.

Where we be

Currently Titania is still alpha or pre-alpha software. As far as basic functionality like being able to apply XSLT to XML at all, being able to grab the correct XSLT and XML files based on the current Subsite node, being able to split databases up per "indiv" Templates, being able to iterate across an entire Site, have variables be inherited, etc— as far as that basic functionality Titania works. With a few minor hiccups it could be used to generate a website as simple as this one, or as complex as my main site. We'll discuss those hiccups later.

Titania drew extensively on the groundwork laid by my current data-driven website code "SiteGen" (see History), but it is also a complete redesign with different goals, assumptions, and layout. The first major milestone has been reached: come up with a website ontology and program design, and make it work. Titania is an entirely different beast than "SiteGen", which even being at v5.0—that's four major rewrites—even at v5.0, SiteGen has a somewhat splintered design based on its ad hoc history. Instead, Titania is well on its way to being a true, generalized framework rather than an application designed around my needs. So don't be misled by the 0.2 version, it's the second alpha version of a v6.0 rewrite.

The second major milestone is not just to get something that's "mostly equal" to SiteGen, but something that is truly equal, something that can replace SiteGen even if it doesn't yet add many new features. After that, further milestones will have to do with adding features, improving performance, and the like.

Another thing about where we are. I just recently adopted the "titania" name, changed the pbwdm namespace URI, and modified the licenses under which pbwdm is distributed, so I'm still in the process of making sure all documentation is updated appropriately. So if you see anything out of whack, try not to be too concerned I should have it fixed soon. (The website as a whole should be completely updated.)

Whither we're headed

Littered all throughout these pages are discussion of where we're headed. But here's something of a synopsis. First and foremost, Titania needs to be brought completely up to par. What it will take for that to happen is that Titania should be able to replace my current website software, which means at a bare minimum we need to:

The last two points are minor things that SiteGen doesn't really do, but they're on the list before making it to the next milestone. Also before Titania can be released as version 1.0 (a milestone long off indeed), interactive/active/dynamic/CGI capabilities need to be developed. In addition to merely creating pages, one long term goal for the CGI usage is to have caching abilities.

Embedded XSLT

Sometimes you may want to combine multiple databases into a single output file. When you want to do this there are two circumstances. (1) You do the same thing frequently, (2) you do it once or twice in unique circumstances. For the first circumstance you just put the relevant code in the XSLT files, easy. This would be stuff like a "recent updates" box in the menu bar for your site; it's on every/most pages.

For the second circumstance, however, it's a bit more complicated. This is the sort of circumstance that would arise from things like the "latest blog post" on my home webpage; there's only one thing like it in the entire site. The solution I'm trying to work with here is to have the code for that box in the database file itself. To do this we need a method of embedding XSLT within the XML data, but then to execute it as if it were called normally from the XSLT file.

I'm thinking this will require treating files in two passes, the first pass to resolve embedded XSLT, the second pass to parse as normal. The reason for doing this route is I may want to render whatever database I'm importing stuff from into elements of the normal variety for the file doing the import, and they should then be treated as they normally would be by the template.

Footnote Transformations

One of the features my current software offers that Titania should be able to handle is properly rendering inline footnotes (endnotes, etc). That is, if I were writing this sentence and had a footnote[1] the content of that footnote would be written embedded in the text of this paragraph, not as a new paragraph at the end of this section. In addition to merely moving the footnotes and leaving a superscript where they were, it also has a running counter that numbers them sequentially. The exact formatting of the superscript and the moved footnote (stuff like the anchor link and the brackets) is then left to the XSLT (which could deal with them in a number of ways including omitting them entirely if it wanted to).

[1] like this.

Non-emulated Paperboy

Presently Titania is using a pure Perl emulation of paperboy. While it's good to offer the pure Perl alternative, to stay true to the original mission (and most likely for sustained performance) Titania needs to be made to work with paperboy.

This is a medium term goal as it depends on development in the Paperboy RSS project. The official v1.0.0 press-release of Paperboy RSS came out on 5 October 2005. Work has begun on switching the project over to being library driven which would be the largest change for a v2.0.0 release. To eliminate severe performance issues, and necessary information going out of scope, this change is essential for Titania to use Paperboy. Once this occurs, XML::Paperboy will become an API for libpaperboy rather than for the paperboy executable, and other modules will be adjusted accordingly.

Part of the reason for needing this library approach is to be able to formulate pbmodperl in a meaningful way, and part of it is to keep from parsing and reparsing files.

Complex Database Nodes

In the discussion of the website ontology, I discuss two options for expanding the Database node type: "parallel" and "serial" databases; the complexities for both of which should be invisible to the viewer or user (see the page). Parallel databases would be a way of saying that two XML files have equivalent content. This would be used for, say, having a translation of your website; each of your parallel databases would have the content in a different language. Serial databases, on the other hand, have to do with breaking up very large single databases which are internally arranged serially somehow (say chronologically as weblogs are). Both of these enhancements are high on the list to be completed, but are large long term goals.

Oberon

Once Titania is sufficiently stable, work will begin on Oberon an SQL-XML bridge; this is a long term goal and is still very far off.