'''Use XsltLanguage as a "soft layer"''' Problem: You need to manipulate, extract, summarize, reduce, or otherwise affect data on disk or in memory. The data is inherently XML-like (either sourced from XML or destined to eventually be XML). You may be tempted to manipulate, extract, etc. the data using the SAX or DOM API in the application language (e.g. Java, C++), '''especially''' if you already have the data in memory from a previous step. '''Instead''', apply an XSLT stylesheet to the data, using XSLT to AlternateHardAndSoftLayers. * As a DomainSpecificLanguage, XSLT is more expressive '''for most problems''' than the equivalent API calls. * A stylesheet is faster and easier to develop and test than application code. * There are (or will soon be) more and cheaper people with XSLT skills than "real" programming skills (not to mention knowledge of your codebase). * Adds a level of indirection to keep "policy" configurable and agile. See searching example below. You can generalize this, as in ApacheCocoon, into an XmlPipeline, where the application language is mostly used to create "generators" for data which is then transformed by one or more XSLT transformations. Of course, when you find a performance bottleneck or run into something that's difficult in XSLT (I think XSLT is great, but everyone hits its ceiling eventually), you can move work down to the hard layer. Even then, it's better to have the hard layer add "hints" to the XML rather than doing a lot of manipulation in the hard layer. '''Examples''' * When I built a documentation engine for an internal language, in essence I wrote just enough code to build XML descriptions of each individual piece, glommed it all together into one document, then relied on XSLT to sort, correlate, and cross-reference it all. * In my documentation builds, I apply a stylesheet to extract everything "searchable" from the XML docs for indexing, and a stylesheet to extract everything "spell-checkable" for spell-checking. This lets me easily change the policy of what's searchable and spell-checkable without touching application code. -- MattChaput ---- See also: TestingXslt ---- CategoryXml