Yeah, this is absolutely right. The typical xml publishing flow looks something like this,Most XSLT users process data server-side and then send the result of the transformation to the client. This is a safer approach than sending XML and XSLT to the client.
[xml source (docbook/openoffice/xhtml)]
feeds into
[business logic xslt]
which feeds into
[web presentation logic xslt] or [print presentation logic xslt] or [pda presentation logic xslt]
and then it's sent to the outside world.
Typically this type of flow from one bit of xslt to the next is called a "pipeline", and there's software to assist you in creating these and aggregating the results. You can construct pipelines in any language by pushing the output from one transformation into another, but these frameworks will cache each stage of the pipeline and skip the regeneration if the files haven't changed, and other features to ease development. Specifically, there's Apache Cocoon which has been in heavy use around the world for years. I've used it in a few commercial projects and it's one of those frameworks that makes the job so much easier. There's my ripoff of Cocoon in PHP called Phpilfer, http://holloway.co.nz/phpilfer which has some (in my opinion) important technical changes to make it faster than Cocoon (although less XML'y). Phpilfer isn't ready for production use yet but I'm putting out a site in it over christmas so that'll be a good test.
Mostly, the benefit of XSLT is that you start with these media-independent source files that you can convert to web, print, voice, xbrl, rss, any format, and it's a well-tested tech that people are using every day. If you're a publishing house, or you have a lot of content on your website, then these highly structured media-independent source files are your gold. People should be more wary of producing source documents, spending weeks editing them, and then locking them up in a loosely structured format (like MSWord, PDF) that other software can't easily get into. XML publishing is about fixing all that.
There's this mediocre presentation for the Wellington PHP user group a few years ago about XML publishing, http://holloway.co.nz/wellypug/publishing/
Jonathan T. Sage wrote:
Since this list is standards based, and I've yet to see any real writeup about XSLT and what it is capable of, I figured a would share what I found with all of you. More information about what I did is available here:
http://jtsage.com/apathy/archives/2004/12/08/xslt-part-1/
and here:
http://jtsage.com/apathy/archives/2004/12/09/xslt-part-2/
1) I think most people aren't sending XSLT to the browser.
2) The CDATA section should probably be just tags because it looks like XML to me. If you can't trust that your source is going to be valid XML then I guess you can use HTML Tidy on it.
Generally there are some approaches in XSLT that are good,
- Try to use many <xsl:template match>s and <xsl:apply-templates/> rather than matching the root node, writing a template, and copying in the bits you want. That way you be more discriminant about what's allowed through.
- Try to use namespaces, rather than writing tags, even if it means creating your own. As you're writing html, set the default namespace to XHTML (or html 4.01, whatever). That way if you integrate with another feed of xml you can distinguish your html from the other stuff.
Here's a good XSLT FAQ, maintained by my guru, Dave Pawson, http://dpawson.co.uk/xsl/sect2/sect21.html
.Matthew Cruickshank http://holloway.co.nz/ ****************************************************** The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ******************************************************
