When offering content on a website, many webmasters find that they must consider the context of that content. Will it be offered as HTML? A PDF document? Or do you want to let your visitors choose? If you choose the last option, how do you avoid having to redo the entire document by hand in each format? XML lets you generate context-specific representations of rich content sources through both modular construction and data transformation. This article is taken from chapter one of XML Publishing with AxKit by Kip Hampton (O'Reilly, 2004; ISBN 0596002165).
XML as a Publishing Technology - Exploding a Few Myths About XML Publishing (Page 2 of 5 )
XML and its associated technologies have generated enormous interest. XML pundits describe in florid terms how moving to XML is the first step toward a Utopian new Web, while well-funded marketing departments churn out page after page of ambiguous doublespeak about how using XML is the cure for everything from low visitor traffic to male-pattern baldness. While you may admire visionary zeal on the one hand and understand the simple desire to generate new business on the other, the unfortunate result is that many web developers are confused about what XML is and what it is good for. Here, I clear up a few of the more common fallacies about XML and its use as a web-publishing technology.
Using XML means having to memorize a pile of complex specifications.
There is certainly no shortage of specifications, recommendations, or white papers that describe or relate to XML technologies. Developing even a cursory familiarity with them all would be a full-time job. The fact is, though, that many of these specifications only describe a single application of XML. Unless that tool solves a specific existing need, there’s no reason for a developer to try to use it, especially if you come to XML from an HTML background. A general introduction to XML’s basic rules, and perhaps a quick tutorial or two that covers XSLT or another transformative tool, are all you need to be productive with XML and a tool such as AxKit. Be sane. Take a pragmatic approach: learn only what you need to deliver on the requirements at hand.
Moving to XML means throwing away all the tools and techniques that I have learned thus far.
XML is simply a way to capture data, nothing more. No tool is appropriate for all cases, and knowing how to use XML effectively simply adds another tool to your bag of tricks. Additionally (as you will see in Chapter 9), many tools you may be using today can be integrated seamlessly into AxKit’s framework. You can keep doing what worked well in the past while taking advantage of what AxKit may offer in the way of additional features.
XML is totally revolutionary and will solve all of my publishing problems.
This is the opposite of the previous myth but just as common. Despite considerable propaganda to the contrary, XML offers nothing more than a way to represent information. In itself, XML does not address the issues of archiving, information retrieval, indexing, administration, or any other tasks associated with publishing documents. It may make finding or building tools to perform these tasks simpler, faster, more straightforward, or less ad hoc, but no magic is involved.
XML is useful only for transferring data structures among web services.
Two popular exchange protocols, SOAP and XML-RPC, use XML to capture data, but suggesting that this is the only legitimate use for XML is simply wrong. In fact, XML was originally intended primarily as a publishing technology. Tools such as SOAP only emerged later when it was discovered that XML was quite handy for capturing complex data in a way that common programming languages could share. To say that XML is only useful for transferring data between applications is a bit like saying that the ASCII text format is only useful for composing email messages—popular, yes; exclusive, no.
My project only requires documents to be available to web browsers as HTML; using XML would add complexity and overhead without adding value.
It is true—needing to deliver the same content to different target clients is a compelling reason to consider XML publishing, but it is certainly not the only one. Separating the content from its presentation also provides the ability to fundamentally alter the look and feel of an entire site without worrying about the information being communicated getting clobbered in the bargain. Similarly, new site design prototypes can be created using the actual content that will be delivered in production rather than the boilerplate filler that so often only favors the designers’ sense of aesthetics.
As for performance, true XML publishing frameworks such as AxKit offer the ability to cache transformed content—even several views of the same document—and will only reprocess when either the source XML or the stylesheets being applied are modified (or when explicitly configured, reprocess for each request). The latest data available shows that AxKit can deliver cached, transformed content at roughly 90% of the speed (requests per second) offered by serving the same content as static HTML.
This article is excerpted from XML Publishing with AxKit by Kip Hampton (O'Reilly, 2004; ISBN 0596002165). Check it out at your favorite bookstore today. Buy this book now.