Web Developer's Virtual Library: Encyclopedia of Web Design Tutorials, Articles and Discussions


WDVL Newsletter

Active Server Pages
JSP/Java Servlets
Microsoft SQL Server
Daily Backup
Dedicated Servers
Streaming Audio/Video
24-hour Support    

jobs.webdeveloper.com

Hiermenus


e-commerce
Partner With Us















Developer Channel
FlashKit.com
JavaScript.com
JavaScriptSource
Developer Jobs
ScriptSearch
StreamingMediaWorld
Web Developer's Journal
Web Developer's Virtual Library
WebDeveloper.com
Webreference
Web Hosts
XMLfiles.com

internet.com
IT
Developer
Internet News
Small Business
Personal Technology

Search internet.com
Advertise
Corporate Info
Newsletters
Tech Jobs
E-mail Offers


XSLT and Alternatives - Page 2

October 19, 2001

Other ways exist for transforming XML documents. These options fall into two categories:

  • XML-related libraries added to general purpose programming languages such as Java, Perl, Visual Basic, Python, and C++
  • languages such as Omnimark and Balise designed specifically for manipulating XML (and, typically, SGML) documents

So why use XSLT? For one thing, it’s a standard. This doesn’t necessarily make XSLT a good language, but it does mean that multiple vendors worked on it together, each contributed to its design, and each has committed to supporting it in their products. XSLT wasn’t invented by some guy who started a company to sell it and then added and dropped features and platform support over the years as it fit the needs of the company’s bigger customers. XSLT’s features and platform support reflect a broad range of interests, and the wide availability of open source implementations make it easy for most programmers to put together their own customized XSLT processors with any features they may want to add.

Being a W3C standard also means that XSLT fits in with other W3C standards and that future W3C standards will also fit in with it. The phrase “standards-driven” is nearing tiresome buzzword status these days as more products take advantage of XML; unfortunately, many ignore important related W3C standards. For example, one XML transformation product has various specialized element types whose names you’re not allowed to use for your own element types. If this product declared and used a namespace for their specialized element types they wouldn’t need to impose such arbitrary constraints on your application development—for example, if they declared a URI and a prefix for this set of element and attribute names, and then used that prefix in the document with those names to prevent an XML parser from confus- ing them with other elements and attributes that may have the same name.

Another advantage of XSLT over other specialized XML transformation languages is that a series of XSLT document transformation instructions are themselves stored as an XML document. This gives XSLT implementers a big head start because they can use one of the many available XML parsers to parse their input. It also means that developers learning XSLT syntax don’t need to learn a completely new syntax to write out their instructions for the XSLT processor. They must just learn new elements and attributes that perform various tasks.

Documents, Trees, and Transformations

Speaking technically, an XSLT transformation describes how to transform a source tree into a result tree. Informally, we talk about how XSLT lets you transform documents into other documents, but it’s really about turning one tree in memory into another one. Why?

Most XSLT processors read a document into the source tree, perform the transfor-mations expressed by the XSLT stylesheet to create a result tree, and write out the result tree as a file, with the net result of converting an input XML document into an output document. Nothing in the XSLT specification requires these processors to read and write disk files; by leaving files and input/output issues out of it, the spec offers more flexibility in how XSLT is used. Instead of an XML file sitting on your hard disk, the input may come from a Document Object Model (DOM) tree in memory or from any process capable of creating a source tree—even another XSLT transformation whose result tree is the source tree for this new transformation. (The DOM is a W3C standard for rep-resenting and manipulating a document as a tree in memory.) How would you tell a pro-cessor to treat the result tree of one transformation as the source tree of another? See the documentation for your XSLT processor. As I said, the XSLT spec deliberately avoids input and output issues, so that’s up to the people who designed each processor.

Similarly, the processor doesn’t have to write out the result tree as a disk file, but can store it as a DOM tree, pass it to a new XSLT stylesheet that treats that result tree as the source tree of a new transformation to perform, or pass it along for use by another program via some means that hasn’t been invented yet. Figure 1.3 shows these relationships when using XSLT to create an HTML file from a poem document type.

Figure 1.3 Document trees, XSLT, and XSLT processors

What Is XSLT (And XSL, And XPATH)?
XSLT Quickly
XSLT and Alternatives (Con't) - Page 3


Up to => Home / Authoring / Languages / XSL / Quickly




Jupiter Online Media: internet.comearthweb.comDevx.commediabistro.comGraphics.com

Search:

Jupitermedia Corporation has two divisions: Jupiterimages and Jupiter Online Media

Jupitermedia Corporate Info


Legal Notices, Licensing, & Permissions, Privacy Policy.

Web Hosting | Newsletters | Tech Jobs | Shopping | E-mail Offers