لطفا منتظر باشید ...
Chapter 3: Transforming XML with XSLT and XPath
Overview
last chapter, one open XML standard that has caught tremendous traction in the industry is the W3C Extensible Stylesheet Transformation (XSLT) specification. Many companies have built XSLT engines and applications according to this specification, which is traditionally embodied in an XSLT processor, to be generally invoked following the parsing and validating of the XML document.Because XSLT is a function-based language, programmers who are used to procedure-based and object-oriented programming languages may have difficulty picking it up. An XSLT stylesheet will include one or more templates formatted in XML that are applied to the entire input XML document. XSLT is a feature-rich language, and version 2.0 will extend it considerably in the area of supporting XML Schema and data types. Whole books have been written on the language, so we are not going to cover that here. Instead, we will focus on integrating the Oracle XSLT processors into your applications.Using an XSLT processor, you can transform an XML document into another XML document, an HTML document, or a variety of other text formats. The processor can be invoked either programmatically (using the given APIs) or from the command line, and takes, as input, the XML document (to be transformed) and the XSLT stylesheet that operates on it. It performs the transformation specified by the XSLT stylesheet and generates either a result DOM tree or a text output stream. The diagram shown in Figure 3-1 represents the architecture of the XSLT processor.
Figure 3-1: The Java XSLT processor architecture
As mentioned, the XSLT processor operates on two inputs: the XML document to transform and the XSLT stylesheet to use. It calls out to an XPath engine whenever it needs to match patterns. The XPath engine often needs to traverse the XML DOM tree to retrieve nodes; it passes these nodes back to the XSLT processor. Whenever the XSLT processor needs to generate a result node, it generates a special XSLT event. This event is handled by an XSLT event handler, serving as a midtier caching agent, which waits for subsequent events that affect the same result node. A simple example of this is when the result node to be built is an XMLElement. Multiple XSLT events, such as one to create the element simply followed by several that depict its attributes, may be generated by the XSLT processor. Once the XSLT event handler gets complete information about a node, it generates an appropriate SAX event, which can then be processed by a registered SAX handler.Currently, two output mechanisms are supported by the XSLT Processor for Java: a DOM tree and a text output stream. Either of these mechanisms can be invoked through appropriate API calls made using the XSLProcessor class. If the API to build a result DOM tree is invoked, a DOM tree builder is registered as the SAX event handler for XSLT. Similarly, if the API to output to a text stream is invoked, an OutputWriter is registered as the SAX event handler. The advantage of this architecture is that a DOM tree is not built as the result tree unless you require it. If your XSLT application simply needs a text output (such as HTML), you can use the less memory-intensive OutputWriter mechanism to do the processing. Remember, if your XSLT stylesheet contains xsl:output instructions, you must use the OutputWriter mechanism for these instructions to be interpreted correctly.
