<xsl:select value-of = "document($uri)/more/xpath/to/*[@id=$id]" > <!-- do stuff here --> </xsl:select>...so that all you'd need to do an otlml-blog are two stylesheets. The first slurps all the nodes -- note that
$uri could just as easily live on a local fileshare as on the network -- and builds a new document. The second transforms it into whatever format is being requested. The problem with this scenario is that it's not very smart about caching changes and will trot out across the network to slurp each embedded document, regardless of changes, for every single request. Thinking out loud now: you could enable the necessary feeping creaturitis on the user end to send a Hey, I've changed notice, akin to the UserLand <cloud> thingy. Those changes could be written to the server and read by the XSLT processor which could be taught to return a cache file... but that still has problems since you're can't cache the individual nodes themselves from inside the first stylesheet. Anyway, you get the idea. Meanwhile, Dries writes: See http://www.drop.org/node.php?id=752. We had this thread/discussion (see link above) about template systems, and the use of XSL/XSTL when generating dynamic pages. Most of the others tend to favor Smarty, FastTemplate and similar template systems, yet I think XSL/XSTL (or after reading your blog maybe OTLML) might be the way to go.The issue, ultimately, revolves around the place where your security, performance and logic requirements meet. I have never been a fan of embedding code in markup. Partly for maintainability, partly for security. But XSLT, like HTML and RSS before it, is a funny beast being used "out of context", as some people in the thread have pointed out. While the built-in logic can be maddenly insufficient, XSLT also has enough power that a malicious or stupid programming error can bring your machine to its knees. So, if you're working in an environment where there are designers and developers and never the two shall meet (they should, but that's another story) you shouldn't fob off the writing of the stylesheets on the designers any more than you would the writing of embedded/evaluated Perl code. For a long time, I was a purist about templates, arguing that the only artificial construct they should contain are substitution variables. Which meant a lot of fucking templates, especially if you were doing tables. Lately, I've been coming around a bit. The ability to pass a data structure other than a scalar and have the tools to read them (minimal conditionals and looping) in place is nice. I'm still not convinced, though. Speaking of emebedded Perl code, I wonder how difficult it would be to write a Template::Toolkit module to build a "smart" OTLML guest/group blog rendering tool...