Recent Specifications

[CR: 20020820]

[December 17, 2003]   W3C Publishes First Working Draft for Extensible Stylesheet Language (XSL) Version 1.1.    W3C has released an initial public working draft for Extensible Stylesheet Language (XSL) Version 1.1, updating the W3C XSL Version 1.0 Recommendation published on October 15, 2001. This specification and a companion Extensible Stylesheet Language (XSL) Version 1.1 Requirements document have been produced as part of the W3C XML Activity by the XSL Working Group. The Extensible Stylesheet Language (XSL) is "a language for expressing stylesheets. Given a class of arbitrarily structured XML documents or data files, designers use an XSL stylesheet to express their intentions about how that structured content should be presented; that is, how the source content should be styled, laid out, and paginated onto some presentation medium, such as a window in a Web browser or a hand-held device, or a set of physical pages in a catalog, report, pamphlet, or book. New functionality has been added in XSL Version 1.1 to support change marks, indexes, multiple flows, and bookmarks. Existing functionality has been extended in the areas of graphics scaling, 'markers' and their retrieval in tables to support e.g., partial sums, and page number referencing. A number of errata changes have been incorporated into the text. This document is expected to be taken through the W3C Recommendation track process. Since first becoming a W3C Recommendation, XSL 1.0 has enjoyed widespread support. However, the user community has expressed requirements that have encouraged various implementations to provide extensions to the language. These extensions -- especially those implemented by more than one implementation -- are clear candidates for standardization so as to maximize interoperability. The XSL Working Group has surveyed and analyzed various existing extensions, user requirements, and features intentionally cut from XSL 1.0 due to lack of time. Using the results of this research, the Working Group is developing the XSL 1.1 version that incorporates current errata and includes a subset of relatively simple and upward compatible additions to XSL."

[August 20, 2002]   W3C Working Groups Update Specifications for XSLT, XML Query, and XPath.    Seven revised working draft specifications have been published by the W3C Working Groups for XML Query, XSL, and XML Schema. Several working drafts represent collaborative work by the XSL and XML Query Working Groups, which are jointly responsible for XPath 2.0, a language derived from both XPath 1.0 and XQuery; the XPath 2.0 and XQuery 1.0 Working Drafts are generated from a common source. The updated working drafts include: XSL Transformations (XSLT) Version 2.0; XML Path Language (XPath) 2.0; XML Query Use Cases; XQuery 1.0: An XML Query Language; XQuery 1.0 and XPath 2.0 Formal Semantics; XQuery 1.0 and XPath 2.0 Data Model; XQuery 1.0 and XPath 2.0 Functions and Operators. Comments on these drafts may be sent to the W3C Query and Transform mailing list ('public-qt-comments') set up for public feedback on W3C specifications published by the XML Query and XSL Working Groups. [Full context]

[December 20, 2001]   New W3C Version 2.0 Working Draft for XSL Transformations (XSLT).    W3C has published a first public working draft for XSL Transformations (XSLT) Version 2.0. The working draft constitutes a revised version of the XSLT 1.0 Recommendation published on 16-November-1999; it thus supersedes XSLT 1.1, which was never developed beyond the Working Draft stage. The version 2.0 XSLT specification "defines the syntax and semantics of XSLT, which is a language for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In addition to XSLT, XSL includes an XML vocabulary for specifying formatting, as defined in XSL Formatting Objects. XSL Formatting Objects are frequently used as the output of an XSLT transformation. XSLT is also designed to be used independently of XSL Formatting Objects. It is often used to produce HTML and XHTML documents, as well as for transformation of application-specific message formats. XSLT 2.0 is designed to be used together with XPath 2.0, which has been developed by the W3C XSL Working Group in collaboration with the XML Query Working Group." The non-normative Appendix E supplies a 'DTD Fragment for XSLT Stylesheets'. [Full context]

[October 16, 2001] Extensible Stylesheet Language (XSL) Version 1.0 Published as W3C Recommendation.

• The World Wide Web Consortium has announced the release of Extensible Stylesheet Language (XSL) Version 1.0 as a W3C Recommendation. The specification represents "cross-industry agreement on an XML-based language that specifies how XML documents may be formatted. It works in concert with XSL Transformations (XSLT), an XML language that performs transformations of structured documents. W3C Recommendation status indicates that a specification is stable, contributes to Web interoperability, and has been reviewed by the W3C Membership, who favor its widespread adoption. XSLT 1.0, the XML language which performs transformations on XML data and documents, has been a W3C Recommendation since November 1999, and already enjoys significant usage in both developer communities and in commercial products. XSL 1.0 builds on XSLT 1.0, and provides users with the ability to describe how XML data and documents are to be formatted. XSL 1.0 does this by defining 'formatting objects,' such as footnotes, headers, columns, and other features common to paged media. Designers would use XSL 1.0 stylesheets to indicate rendering preferences for a type of XML document, including how it is styled, laid out, and paginated onto a presentation medium such as a browser window, a pamphlet, or a book. An XSL engine would take the XML document and the XSL stylesheet, and would produce a rendering of the document. XSLT 1.0 makes it possible to significantly change the original structure of an XML document (automatic generation of tables of contents, cross-references, indexes, etc.), while XSL 1.0 makes complex document formatting possible through the use of formatting objects and properties. As XSL 1.0 is focused on the formatting of paged media, it makes it possible for professional printing capabilities and functions to perform with XML documents today. XSL 1.0 and XSLT make it possible for the needs of Web and print-based media formatting to be met."
• Bibliographic information: Extensible Stylesheet Language (XSL) Version 1.0. W3C Recommendation 15-October-2001. Version URL: http://www.w3.org/TR/2001/REC-xsl-20011015/. Latest version URL: http://www.w3.org/TR/xsl/. Previous version URL: http://www.w3.org/TR/2001/PR-xsl-20010828/. Authors and Contributors: Sharon Adler (IBM), Anders Berglund (IBM), Jeff Caruso (Pageflex), Stephen Deach (Adobe), Paul Grosso (Arbortext), Eduardo Gutentag (Sun), Alex Milowski, Scott Parnell (Xerox), Jeremy Richman, and Steve Zilles (Adobe). Other formats: PDF by RenderX, XML file, single file HTML, ZIP archive. [cache]

[August 29, 2001]   Extensible Stylesheet Language (XSL) Version 1.0 Published as W3C Proposed Recommendation.    The W3C XSL Working Group has published Extensible Stylesheet Language (XSL) Version 1.0 as a W3C Proposed Recommendation, indicating that "the specification is stable and that implementation experience has been gathered showing that the features of the specification can be implemented." The Extensible Stylesheet Language (XSL) "is a language for expressing stylesheets [which] builds on the prior work on Cascading Style Sheets (CSS2) and the Document Style Semantics and Specification Language (DSSSL). Apart from a stylesheet, a processor "could not possibly know how to render the content of an XML document other than as an undifferentiated string of characters. XSL provides a comprehensive model and a vocabulary for writing such stylesheets using XML syntax. Given a class of arbitrarily structured XML documents or data files, designers use an XSL stylesheet to express their intentions about how that structured content should be presented; that is, how the source content should be styled, laid out, and paginated onto some presentation medium, such as a window in a Web browser or a hand-held device, or a set of physical pages in a catalog, report, pamphlet, or book." The PR review period for XSL Version 1.0 which began on 28-August-2001 lasts through 25-September-2001, during which time the W3C Advisory Committee representatives return comments; following the review the W3C Director will announce the document's disposition (W3C Recommendation, Working Draft). [Full context]

[August 24, 2001] "XSL Transformations (XSLT) Version 1.1." W3C Working Draft 24-August-2001. Edited by James Clark. NOTICE: "As of 24-August-2001 no further work on this draft is expected. The work on XSLT 2.0 identified a number of issues with the approaches being pursued in this document; solutions to the requirements of XSLT 1.1 will be considered in the development of XSLT 2.0 [XSLT20REQ -*gt; XSLT Requirements Version 2.0. W3C Working Draft 14 February 2001]. Other than this paragraph, the document is unchanged from the previous version..." Version URL: http://www.w3.org/TR/2001/WD-xslt11-20010824/. Latest version URL: http://www.w3.org/TR/xslt11/. Previous version URL: http://www.w3.org/TR/2000/WD-xslt11-20001212/. Abstract: This specification defines the syntax and semantics of XSLT, which is a language for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In addition to XSLT, XSL includes an XML vocabulary for specifying formatting. XSL specifies the styling of an XML document by using XSLT to describe how the document is transformed into another XML document that uses the formatting vocabulary. XSLT is also designed to be used independently of XSL. However, XSLT is not intended as a completely general-purpose XML transformation language. Rather it is designed primarily for the kinds of transformations that are needed when XSLT is used as part of XSL."

[December 12, 2000] XSLT Revision: W3C Publishes XSL Transformations (XSLT) Version 1.1. XSL Transformations (XSLT) Version 1.1. W3C Working Draft 12 December 2000, edited by James Clark. An HTML version with color-coded revision indicators has been prepared to reveal changes vis-à-vis the W3C Recommendation of 1999-11-16. The non-normative Appendix G supplies a listing of "Changes from XSLT 1.0." Appendix D provides a "DTD Fragment for XSLT Stylesheets." Document abstract: "This specification defines the syntax and semantics of XSLT, which is a language for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In addition to XSLT, XSL includes an XML vocabulary for specifying formatting. XSL specifies the styling of an XML document by using XSLT to describe how the document is transformed into another XML document that uses the formatting vocabulary. XSLT is also designed to be used independently of XSL. However, XSLT is not intended as a completely general-purpose XML transformation language. Rather it is designed primarily for the kinds of transformations that are needed when XSLT is used as part of XSL." Document status: The working draft is based on the W3C XSLT 1.0 Recommendation. The changes made in this document are intended to meet the requirements for XSLT 1.1 and to incorporate fixes for errors that have been detected in XSLT 1.0."

[November 21, 2000] Extensible Stylesheet Language (XSL) Version 1.0. W3C Candidate Recommendation 21-November-2000. See the announcement for details. The new CR has been produced by the XSL Working Group as part of the W3C Style Activity. The Candidate Recommendation review period ends on February 28, 2001. The following exit criteria for the CR (preceding advancement to PR) are proposed: "(1) Sufficient reports of implementation experience have been gathered to demonstrate that XSL processors based on the specification are implementable and have compatible behavior. (2) An implementation report shows that there is at least one implementation for each basic formatting object and property. (3) Providing formal responses to all comments received." [alt URL announcement]

[October 18, 2000] XSL Working Draft. Max Froumentin (W3C XSL Staff Contact) announced the release of a new working draft for Extensible Stylesheet Language (XSL) Version 1.0. Reference: W3C Working Draft 18-October-2000. By Sharon Adler (IBM), Anders Berglund (IBM), Jeff Caruso (Pageflex), Stephen Deach (Adobe), Paul Grosso (ArborText), Eduardo Gutentag (Sun), Alex Milowski (Lexica), Scott Parnell (Xerox), Jeremy Richman (BroadVision), and Steve Zilles (Adobe). Document overview: "This specification defines the Extensible Stylesheet Language (XSL). XSL is a language for expressing stylesheets. Given a class of arbitrarily structured XML documents or data files, designers use an XSL stylesheet to express their intentions about how that structured content should be presented; that is, how the source content should be styled, laid out, and paginated onto some presentation medium, such as a window in a Web browser or a hand-held device, or a set of physical pages in a catalog, report, pamphlet, or book. Formatting is enabled by including formatting semantics in the result tree. Formatting semantics are expressed in terms of a catalog of classes of formatting objects. The nodes of the result tree are formatting objects. The classes of formatting objects denote typographic abstractions such as page, paragraph, table, and so forth. Finer control over the presentation of these abstractions is provided by a set of formatting properties, such as those controlling indents, word- and letter-spacing, and widow, orphan, and hyphenation control. In XSL, the classes of formatting objects and formatting properties provide the vocabulary for expressing presentation intent. The XSL processing model is intended to be conceptual only. An implementation is not mandated to provide these as separate processes. Furthermore, implementations are free to process the source document in any way that produces the same result as if it were processed using the conceptual XSL processing model." WD status: "This version supersedes the previous draft released on March 27, 2000. The working group is issuing this interim public draft as it sets out a number of changes made in response to comments received on the Last Call draft. The Working Group intends to submit a revised version of this specification for publication as a Candidate Recommendation in the near future. Items under consideration for change for Candidate Recommendation include the name of the font-height-override-before and font-height-override-after properties. Discussion is invited and comments can be sent to the editors at xsl-editors@w3.org." The WD is available in several formats: PDF, XML file, HTML single file and .ZIP file.

[August 28, 2000] XSLT 1.1 Requirements. Vincent Quint (W3C/INRIA) recently posted an announcement for the first public release of a new requirements document for XSLT version 1.1: "The W3C Working Group on XSL has just released a document describing the requirements for the XSLT 1.1 specification. The primary goal of the XSLT 1.1 specification is to improve stylesheet portability. The new draft is available at http://www.w3.org/TR/xslt11req. Discussion is invited and comments can be sent to the editors." See XSL Transformations Requirements Version 1.1, W3C Working Draft 25-August-2000, edited by Steve Muench. Description: "In addition to supporting user-defined extensions, numerous XSLT 1.0-compliant processors have exploited the XSLT 1.0 extension mechanism to provide additional built-in transformation functionality. As useful built-in extensions have emerged, users have embraced them and have begun to rely on them. However the benefits of these extensions come at the price of portability. Since XSLT 1.0 provides no details or guidance on the implementation of extensions, today any user-written or built-in extensions are inevitably tied to a single XSLT processor. The XSLT user community has consistently voiced the opinion that the non-portability of stylesheets is a key problem. The primary goal of the XSLT 1.1 specification is to improve stylesheet portability. This goal will be achieved by standardizing the mechanism for implementing extension functions, and by including into the core XSLT specification two of the built-in extensions that many existing vendors XSLT processors have added due to user demand: (1) Support for multiple output documents from a transformation (2) Support for converting a result tree fragment to a nodeset for further processing By standardizing these extension-related aspects which multiple vendor implementations already provide, the ability to create stylesheets that work across multiple XSLT processors should improve dramatically. A secondary goal of the XSLT 1.1 specification is to support the new XML Base specification. This document provides the requirements that will achieve these goals. The working group has decided to limit the scope of XSLT 1.1 to the standardization of features already implemented in several XSLT 1.0 processors, and concentrate first on standardizing the implementation of extension functions. Standardization of extension elements and support for new XML Schema data type aware facilities are planned for XSLT 2.0"

[March 28, 2000] Last Call Working Draft for the W3C Extensible Stylesheet Language (XSL) Version 1.0. The W3C XSL Working Group has released a last call working draft specification for the Extensible Stylesheet Language (XSL) Version 1.0. Reference: W3C Working Draft 27-March-2000, by Sharon Adler (IBM), Anders Berglund (IBM), Jeff Caruso (Bitstream), Stephen Deach (Adobe), Paul Grosso (ArborText), Eduardo Gutentag (Sun), Alex Milowski (Lexica), Scott Parnell (Xerox), Jeremy Richman (Interleaf), and Steve Zilles (Adobe). The draft is available in XML, HTML source, and ZIP archive formats. "The XSL Working Group considers that this draft is stable and ready to move to Candidate Recommendation status, following the successful resolution of comments. This is therefore the last call for comments on this Working Draft. . ." The specification documents "an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary. . . Given a class of arbitrarily structured XML documents or data files, designers use an XSL stylesheet to express their intentions about how that structured content should be presented; that is, how the source content should be styled, laid out, and paginated onto some presentation medium, such as a window in a Web browser or a hand-held device, or a set of physical pages in a catalog, report, pamphlet, or book. . . An XSL stylesheet processor accepts a document or data in XML and an XSL stylesheet and produces the presentation of that XML source content that was intended by the designer of that stylesheet. There are two aspects of this presentation process: first, constructing a result tree from the XML source tree and second, interpreting the result tree to produce formatted results suitable for presentation on a display, on paper, in speech, or onto other media. Formatting is enabled by including formatting semantics in the result tree. Formatting semantics are expressed in terms of a catalog of classes of formatting objects. The nodes of the result tree are formatting objects. The classes of formatting objects denote typographic abstractions such as page, paragraph, table, and so forth. Finer control over the presentation of these abstractions is provided by a set of formatting properties, such as those controlling indents, word- and letter-spacing, and widow, orphan, and hyphenation control. In XSL, the classes of formatting objects and formatting properties provide the vocabulary for expressing presentation intent." [cache]

[March 01, 2000] W3C Releases New Working Draft for Extensible Stylesheet Language (XSL) Version 1.0. As part of the W3C Style Activity, the W3C XSL Working Group has published an updated working draft specification for Extensible Stylesheet Language (XSL) Version 1.0. Reference: W3C Working Draft 01-March-2000, edited by Sharon Adler (IBM), Anders Berglund (IBM), Jeff Caruso (Bitstream), Stephen Deach (Adobe), Paul Grosso (ArborText), Eduardo Gutentag (Sun), Alex Milowski (Lexica), Scott Parnell (Xerox), Jeremy Richman (Interleaf), and Steve Zilles (Adobe). Abstract: "XSL is a language for expressing stylesheets. It consists of two parts: (1) a language for transforming XML documents, and (2) an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary."

[October 30, 2000] XSL Spec of 18-Oct-2000 self-formatted. "This page presents XSL Working Draft of October 18, 2000, formatted as an XSL Formatting Objects document conformant to this same draft. The document has been prepared by the RenderX development team as a contribution to XSL Formatting Objects community." And the related message from Nikolai Grigoriev: We at RenderX have prepared an early XSL FO version of the last XSL Working Draft, (presumably) conformant to this same draft. It can be found at http://www.renderx.com/~grig/xsl2k/, with an example of its formatting by XEP. Please excuse defects in the PDF version - this version of XEP is still under testing. We hope that the XSL Spec may be useful as a maxi-testcase for XSL FO formatters. Any comments/suggestions are welcome. I would be particularly glad to hear opinions about the conformance; I have had nothing but a homegrown DTD to control it..." FO [cache]; PDF [cache]

[October 24, 2000] RenderX DTD for XSL FO. "This DTD has been developed in order to validate XSL FO documents conformant to XSL WD of October 18, 2000. The namespace prefix is xmlns:fo="http://www.w3.org/1999/XSL/Format". This DTD also makes provision for few extensions to XSL WD..." [cache 2000-10-24]

[March 27, 2000] See previous entry. DTD for XSL FO documents. "We (RenderX) have published a DTD for XSL FO WD (March 27 version); used by FOP team to check their tests." [...] This DTD has been developed in order to validate XSL FO documents conformant to XSL WD of March 27, 2000. The namespace prefix is xmlns:fo="http://www.w3.org/1999/XSL/Format". This DTD also makes provision for few extensions to XSL WD, put into a separate namespace: xmlns:rx="http://www.renderx.com/XSL/Extensions". From Nikolai Grigoriev. [cache 2000-03-27 version]

[January 12, 2000] As part of the W3C Style Activity, the XSL Working Group has released a new working draft specification for the Extensible Stylesheet Language (XSL) Version 1.0. Reference: W3C Working Draft 12-January-2000, by Sharon Adler (IBM), Anders Berglund (IBM), Jeff Caruso (Bitstream), Stephen Deach (Adobe), Alex Milowski (Lexica), Scott Parnell (Xerox), Jeremy Richman (Interleaf), and Steve Zilles (Adobe). The revised specification "describes the XSL formatting model, the formatting objects and their properties." This WD updates the previous working draft of 1999-04-21 and provides "additional functionality." Abstract: "XSL is a language for expressing stylesheets. It consists of two parts: (1) a language for transforming XML documents, and (2) an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary." The draft describes the general process of formatting, including the "area model and the formatting-object descriptions and properties and [...] the process of refinement. Formatting is the process of turning the result of an XSL transformation into a tangible form for the reader or listener. This process comprises several steps, some of which depend on others in a non-sequential way. Our model for formatting will be the construction of an area tree, which is an ordered tree containing geometric information for the placement of every glyph, shape, and image in the document, together with information embodying spacing constraints and other rendering information; this information is referred to under the rubric of traits, which are to areas what properties are to formatting objects and attributes are to XML nodes. . . Formatting objects are elements in the formatting-object tree, whose names are from the XSL namespace; a formatting object belongs to a class of formatting objects identified by its element name. The formatting behavior of each class of formatting objects is described in terms of what areas are created by a formatting object of that class, how the traits of the areas are established based, and how the areas are structured hierarchically with respect to areas created by other formatting objects. . . Central to this model of formatting is refinement. This is a computational process which finalizes the specification of properties based on the attribute values in the XML result tree. Though the XML result tree and the formatting-object tree have very similar structure, it is helpful to think of them as separate conceptual entities. Refinement involves (1) propagating the various inherited values of properties (both implicitly and those with an attribute value of 'inherit';), (2) evaluating expressions in property value specifications into actual values, which are then used to determine the value of the properties (3) converting relative numerics to absolute numerics, (4) constructing some composite properties from more than one attribute, (5) converting text nodes to sequences of fo:character formatting objects, (6) creating implied fo:bidi-override formatting objects to support mixed writing directions. Some of these operations (particularly evaluating expressions) depend on knowledge of the area tree. Thus refinement is not necessarily a straightforward, sequential procedure, but may involve look-ahead, back-tracking, or control-splicing with other processes in the formatter..."

[November 16, 1999] XSL Transformations (XSLT) Version 1.0. W3C Recommendation 16-November-1999. Edited by James Clark. Also available in XML format. "This specification defines the syntax and semantics of XSLT, which is a language for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In addition to XSLT, XSL includes an XML vocabulary for specifying formatting. XSL specifies the styling of an XML document by using XSLT to describe how the document is transformed into another XML document that uses the formatting vocabulary. XSLT is also designed to be used independently of XSL. However, XSLT is not intended as a completely general-purpose XML transformation language. Rather it is designed primarily for the kinds of transformations that are needed when XSLT is used as part of XSL."

[October 8, 1999] XSL Transformations (XSLT) Version 1.0 Published as a W3C Proposed Recommendation. The W3C XSL Transformations (XSLT) specification has now been released as a Proposed Recommendation: XSL Transformations (XSLT) Version 1.0. Reference: W3C Proposed Recommendation 8-October-1999, edited by James Clark. This PR is part of the W3C Style activity. The XSLT specification "defines the syntax and semantics of XSLT, which is a language for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In addition to XSLT, XSL includes an XML vocabulary for specifying formatting. XSL specifies the styling of an XML document by using XSLT to describe how the document is transformed into another XML document that uses the formatting vocabulary. XSLT is also designed to be used independently of XSL. However, XSLT is not intended as a completely general-purpose XML transformation language. Rather it is designed primarily for the kinds of transformations that are needed when XSLT is used as part of XSL. . . A transformation in the XSLT language is expressed as a well-formed XML document conforming to the Namespaces in XML Recommendation, which may include both elements that are defined by XSLT and elements that are not defined by XSLT. A transformation expressed in XSLT describes rules for transforming a source tree into a result tree. The transformation is achieved by associating patterns with templates. A pattern is matched against elements in the source tree. A template is instantiated to create part of the result tree. The result tree is separate from the source tree. The structure of the result tree can be completely different from the structure of the source tree. In constructing the result tree, elements from the source tree can be filtered and reordered, and arbitrary structure can be added. A transformation expressed in XSLT is called a stylesheet. This is because, in the case when XSLT is transforming into the XSL formatting vocabulary, the transformation functions as a stylesheet..." Comments on the PR draft may be sent to xsl-editors@w3.org before 5-November-1999, though the working group does not anticipate "further substantial changes to this specification, and encourages active implementation to test this specification during the Proposed Recommendation review period." Public discussion of XSL, including XSL Transformations, is expected to take place on the XSL-List mailing list. The document is available in both XML and HTML formats.

[October 8, 1999] XML Path Language (XPath) Version 1.0 Published as a W3C Proposed Recommendation. As part of the W3C Style activity and W3C XML activity, the XML Linking Working Group and XSL Working Group have published the XPath specification as a PR: XML Path Language (XPath) Version 1.0. Reference: W3C Proposed Recommendation 8-October-1999, edited by James Clark and Steve DeRose. XPath specifies a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer. "XPath is the result of an effort to provide a common syntax and semantics for functionality shared between XSL Transformations and XPointer. The primary purpose of XPath is to address parts of an XML document. In support of this primary purpose, it also provides basic facilities for manipulation of strings, numbers and booleans. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath operates on the abstract, logical structure of an XML document, rather than its surface syntax. XPath gets its name from its use of a path notation as in URLs for navigating through the hierarchical structure of an XML document. In addition to its use for addressing, XPath is also designed so that it has a natural subset that can be used for matching (testing whether or not a node matches a pattern); this use of XPath is described in XSLT. XPath models an XML document as a tree of nodes. There are different types of nodes, including element nodes, attribute nodes and text nodes. XPath defines a way to compute a string-value for each type of node. Some types of nodes also have names. XPath fully supports XML Namespaces. Thus, the name of a node is modeled as a pair consisting of a local part and a possibly null namespace URI; this is called an expanded-name. The data model is described in detail in section 5, 'Data Model'." Available in both XML and HTML formats. Send comments to www-xpath-comments@w3.org until November 05, 1999; such comments are publicly archived.

On July 09, 1999, the W3C issued a revised working draft of the XSLT specification: XSL Transformations (XSLT) Version 1.0, W3C Working Draft 9-July-1999. Edited by James Clark. "Some material that was previously part of this draft has been separated out into XPath; the XPath draft describes the status of everything that is part of XPath. This version of the WD is said to be "nearly stable. The XSL Working Group does not anticipate making technical changes except as necessary to resolve the issues explicitly mentioned in this document." Abstract: "XSLT is a language for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In addition to XSLT, XSL includes an XML vocabulary for specifying formatting."

On April 21, 1999, the W3C XSL Working Group published a working draft version of the XSL Transformations (XSLT) Specification. (W3C Working Draft 21-April-1999). In this draft, XSLT is described as "a language for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML." On April 21, 1999, a new working draft of the Extensible Stylesheet Language (XSL) Specification was also issued by the W3C in conjunction with the release of the XSL Transformations (XSLT) Specification. With the publication of these two draft documents, the two XSL sub-processes (tree transformation, formatting) are explicitly split out, as described in the XSL introduction: "An XSL stylesheet processor accepts a document or data in XML and an XSL stylesheet and produces the presentation of that XML source content as intended by the stylesheet. There are two sub-processes to this presentation process: first, constructing a result tree from the XML source tree and second, interpreting the result tree to produce a formatted presentation on a display, on paper, in speech or onto other media. The first (sub-)process is called tree transformation and the second (sub-)process is called formatting. The process of formatting is performed by the formatter. Splitting the processing of a stylesheet into two sub-processes allows greater flexibility in constructing the presentation of the source content. With tree transformation, the structure of the result tree can be totally different from the structure of the source tree. In constructing the result tree, the source tree can be filtered and reordered, and arbitrary structure and generated content can be added. For example, one could add a table-of-contents a filtered selection of an original source document or one could map the result of a database query (expressed in XML) into a sorted tabular presentation of the relevant portion of the query result. In constructing the result tree, the tree transformation process also adds the information necessary to format that result tree. The second process, formatting, is enabled by making the result tree have formatting semantics. In this recommendation, formatting semantics are expressed in terms of a catalog of formatting objects. The nodes of the result tree are instances of formatting objects. The formatting objects denote typographic abstractions such as page, paragraph, rule, and so forth. Finer control over the presentation of these abstractions is provided by a set of formatting properties, such as indents; word- and letter-spacing; and widow, orphan, and hyphenation control. The formatting objects and formatting properties provide the vocabulary for expressing presentation intent."

On December 18, 1998, Vincent Quint of W3C/INRIA announced the availability of a new Working Draft of the Extensible Stylesheet Language (XSL) Version 1.0 specification. References: WD-xsl-19981216, World Wide Web Consortium Working Draft 16-December-1998. The editors are James Clark (responsible for the 'Tree Construction' portion) and Stephen Deach of Adobe (responsible for the 'Formatting Objects' portion). Abstract: "XSL is a language for expressing stylesheets. It consists of two parts: 1) a language for transforming XML documents, and 2) an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary." The new WD specification is available in HTML, XML, and PDF formats. Discussion on this second WD version is invited and comments can be sent to the editors at xsl-editors@w3.org.

On August 18, 1998, the World Wide Web Consortium (W3C) published the first public Working Draft of XSL 1.0, Extensible Stylesheet Language (XSL) Version 1.0." References: WD-xsl-19980818, World Wide Web Consortium Working Draft, 18-August-1998. The editors are James Clark and Stephen Deach. Abstract: "XSL is a language for expressing stylesheets. It consists of two parts: 1) a language for transforming XML documents, and 2) an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary." According to the W3C press release, "W3C will be developing both the XSL and CSS style sheet languages in parallel, as they are both useful for Web sites and they give Web designers an expanded set of tools to do their work. CSS is used to style HTML and XML documents on the Web. In addition to styling XML documents, XSL is also able to generate new XML documents from XML data. XSL and CSS will share the same underlying concepts and will use the same terminology as much as possible. XSL allows XML data to be abstracted and displayed to the reader in many different ways, generating different virtual XML documents in response to user queries. XSL aims to allow the specification of print styling of Web documents at least as well as a typical wordprocessor. In addition, future support for high-end print typography is planned. XSL allows documents to be written in any language, including historical languages. It allows the specification of any writing direction; the uses for this range from modern Japanese vertical text to ancient Greek and Aztec for scholarly publication." Testimonials for the new XSL Working Draft have been provided by Adobe, Bitstream, Enigma, IBM, Inso, Lotus, Microsoft, Netscape, RivCom, and Sun Microsystems. The press release provides other summary description: "W3C Publishes First Public Working Draft of XSL 1.0. Additional style sheet language extends Web developer toolkit." The announcement is also available in Japanese, Dutch, and Swedish.

The previous XSL 'specification' was (only) in the form of a W3C NOTE: A Proposal for XSL. Reference: NOTE-XSL.html. Dated August 21, 1997 and submitted to W3C on 27 August 1997. Submitted to the W3C by Microsoft, Inso, and Arbortext. Authors: Sharon Adler, Inso Corporation [2000-02 IBM]; Anders Berglund, [IBM]; James Clark; Istvan Cseri, Microsoft Corporation; Paul Grosso, ArborText; Jonathan Marsh, Microsoft Corporation; Gavin Nicol, Inso Corporation; Jean Paoli, Microsoft Corporation; David Schach, Microsoft Corporation; Henry S. Thompson, University of Edinburgh; Chris Wilson, Microsoft Corporation.

The World Wide Web Consortium (W3C) also issued a Working Draft entitled "XSL Requirements Summary" (WD-XSLReq-19980511, W3C Working Draft 11-May-1998). Its editor is Norman Walsh (ArborText, Inc.). Published as part of the W3C Style Activity pertaining to the Extensible Style Language, this requirements document delineates a list of requirements which the XSL Working Group "considers to be in scope for XSL in general with no reference to timing or target version. [it] makes no statement about what specific requirements will be addressed in any particular Working Draft or version of XSL." Requirements are specified for applications that will run in batch as well as in interactive environments. Areas covered in the Working Draft include: General Formatting Issues; Columns, Floats, Keeps, etc.; Fonts; Color; Math; Internationalization; Scripting; Interactivity; Accessibility; Extensibility; Packaging; Meta-information.

Sources:

• Revised Working Draft of XSLT, July 09, 1999

  • XSL Transformations (XSLT) Version 1.0. W3C Working Draft 9 July 1999. HTML Format.

  • XML Format

• Working Drafts of April 21, 1999 (XSLT and XSL)

  • XSL Transformations (XSLT) Specification Version 1.0. W3C Working Draft 21 Apr 1999. Edited by James Clark. Also available in XML format. Local archive copies: HTML, and XML.

  • Extensible Stylesheet Language (XSL) Specification. W3C Working Draft 21 Apr 1999. Edited by Stephen Deach (Adobe Systems Inc.). [local archive copy]

  • XSLT stylesheet - The XSLT stylesheet used to generate the HTML for the April 21, 1999 XSLT draft from the XML source. 'This stylesheet was originally created by Eduardo Gutentag of Sun for an earlier version of the XSL WD and was hacked up by [James Clark] to match the current WD.' [local archive copy]

• Working Draft Version 1.0

  • [December 16, 1998] Extensible Stylesheet Language (XSL) Version 1.0. - World Wide Web Consortium Working Draft 16-December-1998. Available also in XML and PDF formats.

  • [August 18, 1998] Extensible Stylesheet Language (XSL) Version 1.0 - WD-xsl-19980818, Working Draft 18-August-1998. [local archive copy. HTML]

  • Extensible Stylesheet Language (XSL) Version 1.0 - In XML format. [local archive copy, XML]

  • Extensible Stylesheet Language (XSL) Version 1.0 - In PDF format.

  • Press release: "W3C Publishes First Public Working Draft of XSL 1.0. Additional Style Sheet Language Extends Web Developer Toolkit." [local archive copy]

  • Testimonials for XSL 1.0 WD - From: Adobe, Bitstream, Enigma, IBM, Inso, Lotus, Microsoft, Netscape, RivCom, and Sun Microsystems. [local archive copy]

  • James Clark released the alpha version of XT, a Java implementation of the tree construction/transformation half of the W3C's new 1998-08-18 XSL (Extensible Stylesheet Language) Working Draft specification. Revision 1998-08-29.

• XSL Proposal and Requirements Specification

  • "A Proposal for XSL." Dated August 21, 1997; submitted to W3C on 27 August 1997. In HTML format from the W3C Web server

  • XSL Proposal: HTML local archive copy

  • The Proposal Overview. [local archive copy]

  • The press release: from Microsoft, or from ArborText; local archive copy

  • XSL Proposal from Microsoft, Word format

  • "XSL Requirements Summary." WD-XSLReq-19980511, W3C Working Draft 11-May-1998. [local archive copy]

---

Earlier Specifications Documents

• A discussion document "XML Part 3: [NOT YET] Version 1.0" was made available by Jon Bosak as XS-970522 on May 22, 1997. It was a (the final?) version of the DSSSL-o Application Profile produced in the style of a W3C working draft. Available from Jon Bosak via the UNC Sunsite server: Draft for discussion, Postscript format. Part 3 draft: local archive copy in Postscript and in RTF
• Announcement of May 22, 1997 for the preceding XS-970522, from Jon Bosak. The merger of the dsssl-o application profile was referred to as "xs" (xml-style), and the draft document was one "that puts the existing DSSSL Online (dsssl-o) specification in a form that can easily be made into a Working Draft for XML Part 3"
• See also: DSSSL-o, below

---

XSL/XSLT Books

[CR: 20021026]

• XSLT and XPath: A Guide to XML Transformations. By John Robert Gardner and Zarella L. Rendon. Upper Saddle River, NJ: Prentice Hall PTR. ISBN: 0-13-040446-2. xxii + 558 pages, with CD. The book "shows XML programmers how to use XSLT to transform XML documents: XSLT as an XML document instance: leveraging your existing XML skills; XSLT stylesheet concepts and constructs: fundamental through advanced level; XPath patterns and functions; XSLT subroutine functions and variables; XSLT processing of multiple nodes: iterative and conditional XSLT elements; Controlling output options; XSLT extensions." See the sample chapter "Anatomy of an XSLT Stylesheet."

• Practical Formatting Using XSLFO. Extensible Stylesheet Language Formatting Objects. Book excerpt (179 of 341 pages). By G. Ken Holman, from Crane Softwrights Ltd. First Edition, 2001-12-05. ISBN: 1-894049-07-1. 341 Pages. Ken writes: "The XSLFO book is in its first release. This book has hyperlinks from the text of the renditions directly to the W3C Recommendation document, allowing you to learn from our book yet have instant access to the W3C documents. Both editions have the following hyperlinks [note in Acrobat reader the ctrl-left arrow is the Back key]: (1) page references in text (2) chapter references in module summary (3) section references in chapter summary (4) table of subsections at back of book (5) external links to web browser... In addition to the PDF renditions, we now include an accessible version of each of our books and the previews for the books. These renditions use monospaced fonts that are friendly to screen readers. These are produced using XSLFO using RenderX (previous editions were published using DSSSL) ... all our training material is authored in XML..."

• The XSL Companion: Styling XML Documents. By Neil Bradley. London/New York: Addison-Wesley/Pearson Education, [May] 2000. ISBN: 0-201-67487-4. xiv + 318 pages. "A concise, comprehensive and accessible guide to the scope, strengths and limitations of the XSL (eXtensible Stylesheet Language) family of stylesheet standards for XML, this book explains the practical ways in which XSL can be utilized for formatting and manipulating information held in the hugely popular XML data format. This book covers in detail the family of three separate stylesheet which make up XSL: (1) Xpath locates specific information within XML Documents (2) XSLT transforms XML documents into other data formats (3) XSL embeds formatting information in XML documents." See the summary.

• Practical Transformation Using XSLT and XPath (XSL Transformations and the XML Path Language. By G. Ken Holman. ISBN 1-894049-05-5. Eighth Edition. Date: 2000-07-07. "This comprehensive guide to XSL Transformations (XSLT) and the XML Path Language (XPath) according to the XSLT/XPath 19991116 1.0 Recommendations is over 300 pages of explanatory material, diagrams, tables, and code samples. Every markup construct used for XSLT and XPath is identified and described. The focus is primarily on the W3C work and not on archaic definitions or implementations." See details in an online version. To be published in book form by Prentice Hall [2001].

• XSLT Programmer's Reference. By Michael Kay (WWW). Wrox Series: 'Programmer to Progammer'. Chicago / Birmingham, UK: Wrox Press Inc., [April] 2000. ISBN: 1-861003-12-9. Extent: xiv +778 pages. Appendix A: Microsoft MSXML3; Appendix B: Glossary. 3 indexes [Elements, Functions, General]. "XSL (Extensible Stylesheet Language) is the styling language to match XML. XSLT Programmer's Reference is a compact, up-to-date, and relevant explanation of the W3C's XSLT and XPath recommendations. XSLT is notoriously difficult to understand, but this book provides code examples showing how it all ties together and can be effectively employed in a real world development scenario. At the most basic level it allows the programmer to manipulate XML on a template model - XSL provides the template to fit XML data into for displaying on a web page. However, it is capable of much more than that, and allows programmers to selectively query, display and manipulate data, perform scripting-like operations on the XML document and transform it into pure HTML for use on browsers which don't support XML." See the sample chapter (pages 9-43) "XSLT in Context." The Wrox web site provides source code (sample) XML/XSLT documents for tutorial purposes [cache]. See also: (1) the Wrox Press XML book collection on Amazon.com; and (2) the Wrox Press overview.

• XSL-FO: Making XML Look Good in Print. By Dave Pawson. Sebastopol, CA: O'Reilly, August 2002. ISBN: 0-596-00355-2. 282 pages. "Extensible Style Language-Formatting Objects, or XSL-FO, is a set of tools developers and web designers use to describe page printouts of their XML (including XHTML) documents. If you need to produce high quality printed material from your XML documents, then XSL-FO provides the bridge... This book offers in-depth coverage of XSL-FO's features and strengths. XSL-FO teaches you how to think about the formatting of your documents and guides you through the questions you'll need to ask to ensure that your printed documents meet the same high standards as your computer-generated content... Part 1 provides an overview of the technology and introduces the XSL-FO vocabulary. The author discusses how to choose among today's implementations, explains how to describe pages, and shows you what is going on in the processor in terms of layout. You'll learn about the basics of formatting and layout as well as readability. The second part focuses on smaller pieces: blocks, inline structures, graphics, color and character level formatting, concluding by showing how to integrate these parts into a coherent whole." See the description, table of contents, and sample Chapter 6.

• Beginning XSLT. By Jeni Tennison. Wrox Press, May 2002. 700 pages. ISBN: 1-861005-94-6. "This book is divided into two parts. The first part introduces XML and XSLT bit by bit, gradually demonstrating the techniques that you need to generate HTML (and other formats) from XML. The second part pulls together the theory by looking at some of the other things that you can do with XSLT, including generating graphics. Covers: how to create HTML from XML using XSLT; how to organize your XSLT stylesheets using templates; how to sort and number your results; how to use XPath expressions for numerical calculations and string manipulation; how to build dynamic XSLT applications; how to create Scalable Vector Graphics, SVG." See the table of contents and sample Chapter 4 ("Templates"). With sample code. [cache/sample]

News, Articles and Papers: XSL, XSLT, XPath

Surveys, white papers, introductions, tutorials, proposals, posters, news articles, etc.

• [December 03, 2003] "Trees, Temporarily." By Bob DuCharme. From XML.com (December 03, 2003). ['In his latest Transforming XML column Bob DuCharme explains XSLT 2.0's Temporary Trees, and then he demonstrates how to use them.'] " XPath 1.0 has a special data type called Result Tree Fragments. For example, an xsl:variable element can store a single string, but it can also store an XML element with all the descendants and attributes you like. This structure is a Result Tree Fragment... There's little you can do with result tree fragments in XSLT 1.0; you can treat them as strings and you can use xsl:copy-of to copy them to the result tree, and that's it. Because many XSLT developers longed for a way to pass composite structures to named templates, and then use the pieces of those structures individually inside the named template, instead of merely copying the structure to the result tree or pulling substrings out of it, several XSLT 1.0 processors offer extension functions such as Xalan's nodeset() and Saxon's node-set() that convert these fragments to node sets whose nodes can be addressed with XPath expressions. XSLT 2.0 eliminates result tree fragments and replaces them with a more powerful feature: temporary trees. Once you create a temporary tree in an xsl:variable, xsl:param, or xsl:with-param element, you can do anything with it that you can do with a source tree..."

• [September 30, 2003] "Integrating Services with XSLT." By Will Provost. From O'Reilly WebServices.XML.com (September 30, 2003). "For all the magic that XML, SOAP, and WSDL seem to offer in allowing businesses to interoperate, they do not solve the more traditional problems of integrating data models and message formats. Analysts and developers must still plod through the traditional process of resolving differences between models before the promise of XML-based interoperability is even relevant. Happily, there's more magic out there: having committed to XML, companies can take great advantage of XSLT to address integration problems. With XSLT one can adapt one model to another, which is a tried-and-true integration strategy, implemented in a language optimized for this precise purpose. In this article I'll discuss issues and techniques involved in bringing XSLT into web service scenarios and show how to combine it with application code to build SOAP intermediaries that reduce or eliminate the stress between cooperating data structures... XSLT can make many annoying integration problems go away and with relatively low effort at that. We remember that almost all integration issues will require bidirectional transformation. That is, data that's transformed on its way in, and perhaps stored somewhere, will eventually be requested and sent back out, and it will have to look right to the requester. Form is not the only problem here. It is important to avoid the trap of inbound transformations that produce redundant results for different inputs. In other words, there must be a one-to-one mapping between the external and internal value spaces. Precisely preserving information is key to service adaptation, and this is not always so simple.. As wonderful as XSLT is, it's not designed to solve all possible transformation problems. Generally, it's strong on structural work using node sets and progressively weaker working with single values and their components. String arithmetic, algorithms, and math are notable weak points..."

• [September 9, 2003] "Advent 3B2 Launches 3B2-FO, A New XSL-FO Rendering Tool, At Seybold San Francisco 2003." - "Advent 3B2, a leading supplier of standards-based publishing software, is announcing a new, quality-oriented, Extensible Stylesheet Language Formatting Object (XSL-FO) rendering engine called 3B2-FO at Seybold San Francisco 2003. Advent 3B2-FO software has been singled out as a Hot Pick by the editorial staff of The Seybold Report: Analyzing Publishing Technologies, as a product that should not be missed on the show floor... Advent 3B2-FO software supports both simplified yet flexible document production workflows for adding composition and page formatting information to XML documents so they can be printed. In operation 3B2-FO takes either ready-made XSL-FO files containing layout and formatting data, or files containing raw XML content plus an XSLT transformation script, and converts them into printable Postscript or PDF files. Advent 3B2-FO software was developed in accordance with the W3C XSL 1.0 recommendation of October 15, 2001. In addition to providing compliance with the W3C XSL-FO specification, the software engine includes a number of additional functions that provide extended composition and page layout controls. These will give users more versatile document formatting capabilities resulting in higher quality document aesthetics. The additional capabilities in 3B2-FO include controls over vertical justification on a page, extensive hyphenation controls, and the ability to add crop marks and registration marks to a page. Hyphenation features include the ability to specify the number of characters in words that can be hyphenated, the ability to prevent hyphenation at the end of a block and to use caps to keep capitalized words together, spacing controls (plus and minus) for letter and word spacing of text. Advent intends to add additional extended functionality to 3B2-FO over time. 'We announced our intention to develop an XSL-FO rendering tool last year at our annual International Conference in Atlanta,'comments George Punton, President of Advent Publishing Systems. 'We believe that publishers of XML documents will appreciate the advantages 3B2-FO delivers in terms of expanded functionality and the ability to produce higher quality documents compared to the other engines on the market. Should they eventually require even more comprehensive composition and pagination formatting capabilities, our high-end 3B2 software which is also fully XML compliant, is a logical upgrade path.' 3B2-FO is based on the composition and pagination formatting capabilities of Advent's 3B2 professional publishing software which has been in use in high end STM journal, legal, financial, book, and technical documentation publishing environments worldwide for over 16 years. Because it is based on this mature foundation, Advent expects its 3B2-FO software will provide an unprecedented level of performance and reliability... Advents global customer base includes The European Parliament, Boeing, GlaxoSmithKline, the US Patent and Trademark Office, Bertelsmann and the Canadian House of Commons. The Advent Group consists of Advent Publishing Systems UK (the parent company), Advent 3B2 GmbH (Germany), and Advent 3B2 Inc.(USA)..."

• [August 18, 2003] "XSLT Recipes for Interacting with XML Data." By Jon Udell. From XML.com (August 13, 2003). ['Udell explores alternative ways of making XML data interactive using XSLT.'] "In last month's column, 'The Document is the Database', I sketched out an approach to building a web-based application backed by pure XML (and as a matter of fact, XHTML) data. I've continued to develop the idea, and this month I'll explore some of the XSLT-related recipes that have emerged. Oracle's Sandeepan Banerjee, director of product management for Oracle Server Technologies, made a fascinating comment when I interviewed him recently. 'It's possible,' he said, 'that developers will want to stay within an XML abstraction for all their data sources'. I suppose my continuing (some might say obsessive) experimentation with XPath and XSLT is an effort to find out what that would be like. It's true that these technologies are still somewhat primitive and rough around the edges. Some argue that we've got to leapfrog over them to XQuery or to some XML-aware programming language in order to colonize the world of XML data. But it seems to me that we can't know where we need to go until we fully understand where we are... It's crucial to be able to visualize data. As browsers are increasingly able to apply CSS stylesheets to arbitrary XML, the XHTML constraint becomes less important. The Microsoft browser has been able to do CSS-based rendering of XML for a long time. Now Mozilla can too. Safari doesn't, yet, but I'll be surprised if it doesn't gain that feature soon. So while I'm sticking with XHTML for now, that may be a transient thing. Of more general interest are the ways in which XPath and XSLT can make XML data interactive... The techniques I've been exploring for the past few months are, admittedly, an unorthodox approach to building Web applications. The gymnastics required can be strenuous, and some of the integration is less than seamless. But the result is useful, and along the way I've deepened my understanding of XPath and XSLT. Is it really advisable, or even possible, to make XML the primary abstraction for managing data? I'm still not sure, but I continue to think it's a strategy worth exploring..."

• [August 09, 2003] "New and Improved String Handling." By Bob DuCharme. From XML.com (August 06, 2003). ['In the Transforming XML column Bob DuCharme explains some of the new and improved string handling functions -- for concatenation, search, and replace -- in XSLT/XPath 2.0.'] "In an earlier column, I discussed XSLT 1.0 techniques for comparing two strings for equality and doing the equivalent of a 'search and replace' on your source document. XSLT 2.0 makes both of these so much easier that describing the new techniques won't quite fill up a column, so I'll also describe some 1.0 and 2.0 functions for concatenating strings. Notice that I say '1.0' and '2.0' without saying 'XSLT'; that's because these are actually XPath functions available to XQuery users as well as XSLT 2.0 users. The examples we'll look at demonstrate what they bring to XSLT development. The string comparison techniques described before were really boolean tests that told you whether two strings were equal or not. The new compare() function does more than that: it tells whether the first string is less than, equal to, or greater than the second according to the rules of collation used. 'Rules of collation' refers to the sorting rules, which can apparently be tweaked to account for the spoken language of the content... New features such as data typing and a new data model may make XSLT and XPath 2.0 look radically different from their 1.0 counterparts, but many of these new features are straightforward functions that are familiar from other popular programming languages. The compare(), replace(), and string-join() functions, which will make common coding tasks go more quickly with less room for error, are great examples of this...

• [May 14, 2003] "Style Stylesheets to Extend XSLT, Part 2. Improving the Trace Generator." By Joseph Kesselman (Advisory Scientist, IBM). From IBM developerWorks, XML zone. ['In Part 1 of the series, Joe demonstrated the basics of using an XSLT stylesheet to enhance another stylesheet. In this installment he develops a more polished version, making the trace generator more detailed, more selective, and more controllable -- and as a bonus, he includes a reusable XPath generator template.'] "My previous article demonstrated the concept of using a stylesheet to compile new features into another stylesheet. Specifically, I showed you how to write a simple execution tracing tool, which automatically modifies a stylesheet so it will generate comments in the output document as it runs, showing which parts of the latter were produced by each template. However, I ended the article by pointing out that the basic version I'd developed was quite limited, and suggesting a number of ways in which it could be improved. In this installment I'll add some of those missing features, and turn this proof-of-concept into a much more useful tool..." With source code.

• [May 06, 2003] "Style Stylesheets to Extend XSLT, Part 1. Use XSLT as a Macro Preprocessor." By Joseph Kesselman (Advisory Scientist, IBM). From IBM developerWorks, XML zone. May 6, 2003. ['XSLT isn't just about styling documents for presentation. It's actually a very general-purpose document transformation processor. And as Joe demonstrates in this two-part series, stylesheets are themselves documents, so XSLT can be used as a portable preprocessor to automatically enhance the behavior of a stylesheet.'] Joe's note to the XSL list (xsl-list@lists.mulberrytech.com): "The first installment of my article on using XSLT stylesheets to annotate/enhance other XSLT stylesheets just went live on developerWorks. This part's largely motivation and context-setting, though it does introduce the basic tricks which are needed to generate new stylesheet behaviors. The second part (already written, just needs final polishing) will start with this limited prototype and polish it into a more robust and useful tool." From the introduction: "As one of the contributors to Apache's open-source Xalan processor, I've been impressed by the wide range of applications folks are finding for XSLT. Stylesheets have established themselves as a very general-purpose tool, not just for rendering XML documents for display, but for automatically generating new documents... XSLT does have the concept of extensions, which provide an architected way to enhance the stylesheet language. With the extensions, Xalan developers can provide some additional features without conflicting with the standard. But we really can't afford to build every requested extension directly into the processor; we'd wind up with a huge library of infrequently-used features. Xalan does let you write and plug in your own extensions. But extensions are usually limited to defining new stylesheet operations rather than altering existing ones, and usually require that someone write code in a traditional programming language. Future versions of XSLT may let you write extensions in the XSLT language. Also, user-written extensions aren't supported by all XSLT processors, and the details of writing, accessing, and invoking them vary, so this isn't a very portable solution. For example, an extension written for the Java-based Xalan-J processor can't be invoked from the C++ version, Xalan-C, nor vice versa... In this pair of articles, I'll show you another way to enhance XSLT stylesheets, which can do some things extensions can't and which will work in any XSLT processor: write a stylesheet that compiles custom features into other stylesheets! Essentially, we can leverage the fact that an XSLT stylesheet is itself an XML document and automatically apply a set of modifications to add or modify its behavior..." With source files.

• [April 15, 2003] "What's New in XSLT 2.0." By Jeff Kenton. In XML Journal Volume 4, Issue 04 (April 2003). "The XSLT version 1.0 language definition has been an official recommendation of the W3C since 1999. Its use has expanded dramatically in the past 18 months, for processing XML and XML/SOAP security policies and for generating HTML Web pages... Nearly as soon as the language became official, people began proposing to change it. The [revision] effort began as a version 1.1 proposal, which was abandoned in favor of the current Working Draft (WD)... XSLT 1.0 dealt with four types of data: strings, numbers, Booleans, and nodesets. XSLT 2.0 has 48 atomic (built-in) data types, plus lists and unions constructed from them. There are now 16 numeric types; 9 variations of date, time, and duration; plus hexBinary and base64Binary, among others. Users may also create others from the built-in types to suit their needs... XPath 2.0 has generalized its path expressions. Now, a primary expression (literal, function call, variable reference, or parenthesized expression) can appear at any step in the path, rather than just the first step. Basically, this allows any expression that returns a nodeset (sequence of nodes) to appear on either side of a /... One issue that has proven somewhat divisive in version 2.0 is the inclusion of schemas. There are those, including Microsoft and others, who believe that schemas are necessary to what people are doing with the language. Schemas provide both validation of data types in input documents, and clues to the XSLT processor about which data structures to expect. There are others who think it is too complicated, and that schema validation should be a separate process. There are reasonable arguments on both sides. In the end, it was decided to define a conformance level for which schema support was optional. With schema support, there is a new xsl:import-schema declaration. Every data type name that is not a built-in name must be defined in an imported schema. XPath expressions will be able to validate values against in-scope schemas, and will be able to use constructors and casts to imported data types. There are still issues to be resolved before the Working Drafts turn into official W3C Recommendations. Committee members have said that they hope the process will be complete by late this summer or early fall [2003]. Meanwhile, Michael Kay, who is both the editor of the XSLT 2.0 WD and the creator of Saxon, has made a version of Saxon available that supports most of the new proposal. And, of course, most suppliers of XSLT processors are working to support version 2.0 of the language as soon as it becomes official. The committees are doing a great job improving XSLT, and I expect it to be enthusiastically adopted by the XML community..." [alt URL]

• [April 08, 2003] "Fast XSLT." By Steve Punte. From XML.com (April 02, 2003). ['The article focuses on the need for speed in XSLT. The widespread adoption of the W3C's XML transformation language has led to a demand for fast, conformant XSLT processors. One way of achieving speed is to pre-compile XSLT stylesheets. Steve Punte concentrates on that technique in "Fast XSLT." Steve tracks the emergence of Apache XSLTC and its modern competitor, Gregor.'] "This article reviews the birth and development of the promising compiled-XSLT engine, Apache XSLTC, and the fierce competition among developers of XSLT engines to be the performance leader... Apache XSLTC began in early 2000 at Sun Microsystems, first with Jacek Ambroziak and eventually turning into a small team. XSLTC is most significantly differentiated from other transformer engines by its distinctive two-phase operation. The XSL stylesheet is first compiled into a Java class called a 'translet' ('transformer servlet', not related to a web application servlet). This stand-alone translet can be loaded as a Java class and run in a different process or even on an entirely different machine. The core translet accepts a DOM-like object for input and produces a SAX-like output stream. Adaptors are provided to convert to all conventional standards. But Jacek Ambroziak has wiped the plate completely clean and started a new XSLT engine, which he calls 'Gregor', at his new firm Ambrosoft. As Jacek says, 'In the case of XSLTC (and especially Gregor) it is not only compilation but sets of particular algorithmic ideas that matter a lot for performance (speed/memory)'. In early testing, Gregor is tentatively showing nearly ten times the performance of Xalan-J and twice that of XSLTC; but it is not a complete product yet. Benchmarks can be misleading... In the end, the question always remains, 'are their sufficiently radical and advantageous architectural approaches that can improve performance yet unexplored and untapped?' In the case of XSLT engines, the answer is 'probably', since it's a very young field... Compilation to bytecode is just one of many tactics being utilized in the XSLT performance race. It is possible that additional significant gains will also be obtained in other areas such as intelligent pre-optimization of stylesheets, clever internal data structures, or even a more hot-spot like run-time optimizer. Most likely the field will remain competitive, each product achieving improvements and gains on a year-to-year basis, new contenders coming onto the scene, and some old ones slipping off. Performance is difficult to quantify and predict and highly dependent upon the exact customer usage. For performance in critical situations it is recommended that a small handful of the dominant engines be tested in a particular application before a final decision is made..."

• [April 08, 2003] "Conditional Execution." By Bob DuCharme. From XML.com (April 02, 2003). ['Bob DuCharme is back for his monthly Transforming XML column. Bob explains the use of the conditional constructs xsl:if and xsl:choose in order to selectively execute part of a stylesheet.'] "Most programming languages provide some means of conditional execution, which allows a program to execute an instruction or block of instructions only if a particular condition is true. Many programming languages do this with if statements; the XSLT equivalent is the xsl:if instruction. There's ultimately only one instruction that can or can't happen in XSLT based on the boolean value of an xsl:if element's test expression: nodes get added to the result tree or they don't. The addition of nodes to the result tree is the only end result of any XSLT activity, and the xsl:if element gives you greater control over which nodes get added than template rule match conditions can give you. For example, an xsl:if instruction can base its behavior on document characteristics such as attribute values and the existence (or lack of) specific elements in a document. Many programming languages also offer case or switch statements. These list a series of conditions to check and the actions to perform when finding a true condition. XSLT's xsl:choose element lets you do this in your stylesheets...

• [March 07, 2003] "Peek Into the Future of XSLT 2.0." By Charles White. From DevX.com (March 04, 2003). ['XSLT 2.0 provides powerful new features that XSLT 1.0 was missing. Although XSLT 2.0 is still under development, Mike Kay's Saxon 7 implementation lets you experiment with the new capabilities now.'] "XSLT is beginning to take root into a large base across the enterprise. So what happens? Just as developers begin to get comfortable with XSLT, XSLT 2.0 and XPath 2.0 begin to creep up on them from around the corner. And it's fair to say that XSLT 2.0 is not your mother's XSLT. In fact, XSLT 2.0, XPath 2.0, and XQuery are now so interconnected that if you master one, you can easily master them all. So when you're done with this article, make a note to yourself to study XPath 2.0 when it receives formal recommendation status as a standard from the W3C. This article will introduce you to some of the most interesting core concepts of XSLT 2.0 and its companion, XPath 2.0. While it doesn't cover all the changes to these languages, it will introduce you to the most interesting new features. The brief example at the end of this article may help to tie some of this information together. Like its predecessor XSLT 2.0 relies heavily on XPath (now XPath 2.0) for many of its core features. XPath 2.0 is itself intertwined with yet another emerging standard, XQuery 1.0, which relies on XPath 2.0 so much that after mastering XPath 2.0 you'll have a pretty good idea how XQuery works. It's important to note though that XSLT 2.0 does not rely on XQuery. XQuery is a language for querying XML documents and is already finding substantial support in most of the native XML databases such as XIndice, Ipedo, XHive, and others. In addition, both Microsoft and Oracle plan to support XQuery in their next major releases, which will have native XML database capabilities. Eric Brown, Microsoft's Product Manager for SQL Server, says that the next release of SQL Server, code-named Yukon, will support the following XML features: (1) Native XML Storage, (2) XQuery Support, (3) Cross domain querying between relational and XML data. Some developers are even suggesting that XQuery will supplant XSLT as the primary XML processing language. Other than their common bond to XPath, however, there is no direct relationship between XSLT 2.0 and XQuery... In XSLT 1.0 (and XPath 1.0), there were four kinds of data types: Strings, Booleans, Node-sets, and Numbers. Node-sets, of course, contain nodes, which in turn contain some properties. There are seven types of nodes, the document, element, attribute, text, namespace, processing instruction, and comment nodes. XPath 2.0 has a much richer data model. At the very top of the list is the sequence, which in addition to nodes can consist of XML Schema Language simple types such as xs:int or xs:date, and is equivalent to an ordered list. The addition of XML Schema data types is the biggest change. There are 16 simple data types available through Schema, and XQuery provides for functional access to all of them..."

• [February 19, 2003]   XSL-FO Implementation in the Sun xmlroff XSL Formatter SourceForge Project.    A communiqué from Eduardo Gutentag describes the release of the Sun xmlroff XSL formatter as a SourceForge project. The xmlroff XSL Formatter "is written in C and currently produces PDF output using the PDFlib library. It uses libxml2 and libxslt plus the GLib, GObject and Pango libraries that underlie GTK+ and GNOME, although it does not require either GTK+ or GNOME. xmlroff represents Sun's newest open source donation is an implementation of the W3C's Extensible Stylesheet Language specification, also known as the Extensible Stylesheet Language Formatting Objects specification (XSL-FO). Drawing on previous work in CSS2 and DSSSL and and other information formatting standards, XSL-FO defines a collection of page layout semantics in XML -- such as page numbering -- that makes it easier for data to be both easily navigable through Web-based readers, such as Web browsers or PDF readers, as well as cleanly read when printed. Sun's open source XSL-FO engine helps developers to create consistent formatting results for published data across an array of languages, which equals lower costs through reduced development time and minimized errors and is designed to support full internationalization.

• [February 18, 2003] "EXSLT By Example. How to Put the Community Standard XSLT Extensions to Work." By Uche Ogbuji (Principal Consultant, Fourthought, Inc). From IBM developerWorks, XML zone. February 2003. ['Community standards have had a very important role in XML technology, from SAX to RDDL. The most important community standard for XSLT is the EXSLT initiative for standard extension functions and elements. In this article, Uche Ogbuji uses practical examples to introduce and demonstrate some useful EXSLT functions.'] "... the EXSLT extensions make XSLT far more useful in general-purpose data-manipulation tasks. Just to select a few random examples: (1) The EXSLT Math module contains trigonometric mathematical functions, which makes it feasible to generate pie charts in SVG. (2) The EXSLT Regular Expressions module makes it easier to parse and process user input and other variable data sources. (3) The EXSLT Dates and Times module makes it easier to render Web pages with date-sensitive content, or to process data containing date fields... In these and many other real-life tasks, EXSLT makes using XSLT feasible in a way that is portable across the many processors that support the standard. In prior articles, I have already shown how EXSLT functions such as exsl:node-set and exsl:object-type are useful for even the most basic processing tasks. In this article I try to cover a cross-section of EXSLT's capabilities by solving a couple of simple and practical problems using EXSLT. I also try to avoid ground I've already covered to introduce the many useful EXSLT facilities that have not received the attention they deserve. If you are completely unfamiliar with EXSLT, please read the Kevin Williams article first. The resources in that article include pointers to XSLT processors that support EXSLT, which you should install so you can play with the examples and use EXSLT yourself... EXSLT includes tools for making things easier and others for making things possible in the first place. For example, the date:date-time function is impossible to replace in XSLT but dyn:evaluate() can usually be replaced by a system, whereas you use XSLT to generate another XSLT script which is what you actually run to get the desired result. EXSLT includes much more than I can hope to cover in future articles, but one nice thing about EXSLT is that it is very well documented. You'll find a world of riches to improve your XSLT development by checking out the Web site and taking advantage of this community standard..."

• [February 11, 2003] "HTML to Formatting Objects (FO) Conversion Guide. Use These XSLT Templates to Speed Your Conversions of HTML Elements to FO and Thence to PDF." By Doug Tidwell (developerWorks' Cyber Evangelist, IBM developerWorks). From IBM developerWorks, XML zone. February 2003. ['Need help converting HTML documents to PDF? This reference guide shows by example how to use XSLT templates to convert 45 commonly used HTML elements to formatting objects from the XSL-FO vocabulary for easy transformation to PDF using XSLT. The examples assume that you're using the Java-based XSLT processor Xalan and the Apache XML Project's FOP tool, but most of the methods would work just as well with other tools.'] "We all design our HTML pages to look good on the screen, but printing those Web pages is usually an afterthought. To create printable versions of Web pages, the best approach is to use XSLT and XSL-FO to generate a PDF file. You can do the job with an open-source XSLT processor, the XSL Formatting Objects (XSL-FO) vocabulary, and a formatting-object engine. If you already know how to work with XSL-FO and XSLT, this guide provides a valuable resource: It goes through the most common HTML tags and defines how to convert each of them into formatting objects... This guide includes dozens of examples that illustrate how to write XSLT style sheets to do the conversion from HTML element to the corresponding formatting object, the basic building block of documents rendered with XSL-FO..."

• [January 08, 2003]   Xerox Announces Circus-DTE Programming Language for Document Transformation.    [Not XSLT.] An experimental programming language developed at the Xerox Research Centre of Europe in Grenoble, France has been released for testing. Circus-DTE is a "new, innovative programming language designed for document transformation processing. Circus-DTE natively supports XML (DTDs) and is particularly suited to data processing or the transformation of structured documents: it automatically validates the results produced so that input into another application is sure to function properly. XRCE scientists believe that Circus-DTE could be especially useful when there are multiple document transformations, such as document content processing, Internet publishing, publishing on handheld devices and database-to-XML conversions. For example, processing a customer order requires a series of transformations -- data must be input into applications that check inventory and availability, that prepare shipping documentation, that generate an invoice, that process payments and perhaps even publish to the Web so a customer can track progress online. Circus-DTE is a mixture of functional, imperative and declarative programming styles. It is a type-safe compiled language with an embedded interpreter for compile-time evaluation of testing clauses. Circus-DTE incorporates structural matching operators that operate on all types of data. Matching operations involve typechecked filters which are combined up to arbitrary complex levels. Circus-DTE also offers a Linda-like Coordination Memory. Such a model relies on a few basic synchronization primitives and an associative memory that together simplify complex synchronization schemes." The software is downloadable; it runs on Win32, Linux, or Solaris/SunOS platforms.

• [December 19, 2002] "Automatic Numbering, Part Two." By Bob DuCharme. From XML.com December 11, 2002. ['Here we have the second part of "Automatic Numbering", part of Bob DuCharme's "Transforming XML" column. This month, Bob shows how to control section numbering and examines an alternative to <xsl:number> for simple numbering tasks.'] "In last month's column, we saw how XSLT's xsl:number element lets you add numbers to your output for numbered lists or chapter and section headers. We looked at some of the attributes of this element that let you control its appearance -- for example, how to output the numbers as Roman numerals, as letters instead of numbers, and how to add leading zeros. We also saw the basics of numbering sections and subsections, but only the basics. This month we'll learn how to gain real control over section numbering, and we'll look at a more efficient alternative to xsl:number that's sometimes better for simple numbering..."

• [December 18, 2002] "Using XSL Formatting Objects for Production-Quality Document Printing." By Kimber W. Eliot (ISOGEN International, LLC). Presentation given at the IDEAlliance XML 2002 Conference, Baltimore, December 2002. 16 pages. ['PDF paper version produced from XML source via XSL, Saxon and Antenna House's XSL Formatter product.'] Abstract: "The XSL Formatting Objects specification has been a published recommendation for over a year. During that time a number of commercial XSL-FO implementations have become available that make it possible to use XSL-FO for true production-quality creation of printed documents. While there are functionality limitations in XSL 1.0 that limit the types of page layouts that can be created, the page layouts that are supported are sufficient for most technical documentation, such as user manuals, maintenance manuals, and so on. This paper evaluates the XSL 1.0 specification and the currently-available implementations against the print requirements typical of a variety of document types, including technical documents, magazines, and newspapers. We then report our experience in using XSL-FO with commercial tools to produce hardware user manuals for a line of consumer computer peripherals. We discuss the XSLT and XSL issues, as well as XSL-FO extensions that may be required to satisfy typical print production requirements. Finally, we provide a set of recommendations, based on the current state of the XSL specification and the current state of tools, as to when the use of XSL-FO is appropriate and which XSL-FO implementations are best suited to which tasks or disallowed by certain sets of requirements." Summary: "Our experience to date with using XSL-FO for production of high-quality printed documents, primarily technical manuals, has been tremendously positive. At almost every step of the process of implementing FO-based publishing solutions the task has been easier than we expected. We have been pleasantly surprised by the how much easier it is to create and maintain FO style sheets using XSLT as the transformation technology than any other publishing technology we have used in the past. We have been impressed by the quality of the FO implementations and the responsiveness of vendors to problem reports and feature requests." Note the update provided in the posting "Production Quality XSL-FO": "This paper reflects the state of the world as of late October 2002. Since I wrote it, the following FO implementations have been released or announced: (1) Adobe Document Server. Includes an FO-to-PDF component based on top of Framemaker. Doesn't implement as many features as XEP or XSL Formatter, but lets you use Frame-specific functionality from the FO, such as Frame templates. Provides some extensions, including a revision bar mechanism. (2) SUN's xmlroff open-source FO implementation. Written in C. Provides internationalization features, including support for right-to-left writing modes. Feature support is 'almost basic conformance'. Should be released Real Soon Now (just waiting for final approvals). (3) 3B2's to-be-named 'free or almost-free' FO implementation, built on top of the 3B2 formatting engine. (4) Antenna House announced Unix and Linux support in 1Q2003 (they are doing final release testing now). (5) IBM's XFC FO implementation was released as part of a larger AFP product. IBM assures me that it is under active development... It was standing room only by the time I was done presenting my talk, which is pretty good considering I was up against Norm Walsh. From the questions I got asked, it was clear that a lot of enterprises are starting to investigate the use of XSL-FO to do sophisticated page composition..." See the source at IDEAlliance and other ISOGEN white papers. [cache]

• A posting from W. Eliot Kimber (ISOGEN International) announces the creation of an EXSLFO project on SoureForge. The EXSLFO project "is a community effort to define functional extensions to thet XSL Formatting Objects specification in advance of development of new versions of the XSL FO specification by the W3C. It is intended to be an adjunct to the formal W3C specification development process. Expected outputs of this activity are: [1] Clear definitions of requirements for features and functions not addressed by the current FO specification. These features may be core layout functions (e.g., revision bars) or may be related to specific delivery technologies (PDF bookmarks and metadata); [2] Specifications for non-proprietary extensions to the XSL-FO language that attempt to satsify these requirements; [3] Where possible or applicable, implementations of these requirements in whatever form (pre-processors, post-processors, extensions to existing FO implementations, etc.)." Kimber says: "I have created a initial requirements document to serve as a starting point for discussion and a model for the type of requirements the project is intended to gather... a starting point for discussion. The motivation in starting this project is driven largely by a desire to have standardized those extensions that are clearly generally required but probably outside of the scope of the FO spec, such as generation of PDF bookmarks and metadata, capturing of page-to-object mappings, etc. As an integrator, I would like to see an industry standard for these extensions that would allow one to have a single FO instance for a variety of FO implementations that could take advantage of all the features of, for example, PDF." A mailing list has been set up; the Internet domains exslfo.org and and exslfo.com have also been registered for the project.

• [December 09, 2002] "What Is XSL-FO? When Should I Use It? [Tech Watch.]" By Stephen Deach (Adobe). In The Seybold Report Volume 2, Number 17 (December 9, 2002), pages 3-8. ISSN: 1533-9211. ['XSL-FO stands for eXtensible Stylesheet Language formatting objects. It's a language for completely describing a styled document. The second question "When Should I Use It?" is not so easy, but we can oversimplify by saying that layout- and design-intensive publications are probably not good candidates for the XSL-FO approach. Content-driven documents fit the model much better, especially if they must be personalized, produced in high volume or generated in response to Web queries.'] "Generically, XSL is actually a family of three Recommendations produced by the W3C's XSL Working Group: XSL Transformations (XSLT), XML Path Language (XPath), and eXtensible Stylesheet Language (the specific use of XSL). To ease the confusion over the specific and generic uses of XSL, most people refer to the last specification (which actually specifies the formatting objects) as XSL-FO... XSL-FO is an intermediate form between media-neutral XML and media-dependent output. You feed your XML structured content and an XSLT stylesheet to an XSLT processor. The result is XSL-FO. Then you feed the XSL-FO, along with font metrics and any external graphics, into an XSL-FO formatter. The result is a paginated document (in PDF or printer-native code) that can be displayed or printed... The requirements of the publishing industry are broad and diverse. Some documents require the creative professional to interactively modify the layout, the content and the typography to get an acceptable result; other documents are best generated and formatted on demand using rule-based systems. XSL-FO is designed to fill a hole in the format-on-demand sector of this industry; thus it is an ideal fit for batch-pagination products such as Adobe Document Server. The requirements of the format-on-demand sector are quite different from those addressed by interactive, WYSIWYG composition tools such as FrameMaker and InDesign. Today's WYSIWYG composition tools are very good at creating and perfecting individual documents, which is the primary thrust of much of the traditional publishing industry. In these WYSIWYG products, the content and styling and layout are tightly bound within the document, so reflowing the document to an alternate medium (display vs. paper, displays with differing sizes or form-factors) is difficult. Another area where WYSIWYG tools are not so good is producing thousands of documents whose content is pulled from a database and poured into templates. Examples include insurance policies, contracts, manuals, mail-order catalogs with regional or demographic variations, and textbooks and teaching aids with state-by-state or school-district-specific variations. In circumstances like these, the important issue is the ease with which whole collections of documents can be given a common look and feel. In content-driven print-production environments that have hierarchical styling models (such as those commonly used with SGML), users will have no trouble adapting to the use of XSL-FO. It is only necessary to learn XSL-FO's element names, attribute names and attribute-value names... XSL-FO has been a recommendation for only about a year. We are just starting to see the first tools come on the market that simplify its authoring. This is about the same rate of progress as with later versions of HTML, and is faster than we saw with CSS. It took about four years for CSS-1 to be fully adopted. As Web standards become more sophisticated, the adoption rates become slower. For example, the adoption of the majority of CSS-2 is progressing at a somewhat slower rate than CSS-1. Therefore, I expect the significant adoption of XSL-FO to develop over a three-to-five-year time frame..."

• [November 25, 2002] "Tip: Control White Space in an XSLT Style Sheet. Create the Document You Want by Understanding White Space Stripping." By Nicholas Chase (President, Chase and Chase Inc). From IBM developerWorks, XML zone. November 2002. ['Because the style sheet and the source document in an XSLT transformation have different rules regarding white space stripping, it often seems as though the production of spaces and line breaks has no rhyme or reason in the process. This tip shows you how to control the production of white space in a transformation's result, which can lead to documents that more closely align with your requirements. For this tip, you can use any XSLT processor, such as Xalan or Saxon, or a browser-based solution, such as Microsoft Internet Explorer or Mozilla.'] "Before processing a transformation, an XSLT processor analyzes the style sheet and the source document, and removes any applicable white space nodes. It then processes the document, building the result tree from the remaining nodes... When the processor strips the white space nodes from an element, it first checks to see if that element is on a list of white-space preserving elements. By default, all of the source nodes are added to this list, but you can remove one (or more) by adding them to the xsl:strip-space element. For example, you can strip all of the white space nodes out of the question element in order to compress any responses within the question or answer texts... Adding white space to the style sheet: When the processor strips the white space nodes from the style sheet, only one element is, by default, on the list of white space preserving elements: xsl:text. A text element is always preserved, so it can be useful for adding line breaks or spaces within a document... By understanding the rules for white space preservation as they apply to a style sheet or a source document, you can closely control the appearance of the final document, but white space will never be stripped from within a text node..." See also the series "Controlling Whitespace, by Bob DuCharme.

• [November 22, 2002] "Debug XSLT On The Fly: Debugging Tricks That Keep it Simple." By Uche Ogbuji (Principal Consultant, Fourthought, Inc). From IBM developerWorks, XML zone. November 2002. ['Debuggers are very handy in programming, but they can also be complex pieces of software in their own right -- complex to set up, to learn, and to use. Sometimes you just need a quick print-out of some values that you suspect to be at the heart of a specific problem you're seeing. In this article, Uche Ogbuji shows how to do quick debugging using xsl:message and other built-in facilities of XSLT, as well as common extensions in EXSLT.'] "Long before they turn to a debugger, most developers start with the equivalent of a print or printf statement in their programming language to try logging values that might shed some light on their code's errant behavior. XSLT is no exception. You can now get XSLT debuggers and even full integrated development environments (IDEs), but you probably won't always want to go through all the motions of firing up a debugger just to check a single value. This is especially true of those, like me, who use plain old XEmacs (with xslide, in my case) for editing XSLT transforms. xsl:message is usually the best solution for this. You can simply insert a message at the right spot in the right template as a quick debugging tool. The main downside is that there is no standard specification of xsl:message output: It can take the form of a pop-up dialog box, a log file, or -- for command-line XSLT processors -- a marked display to the standard error output. Usually, this is a minor matter; a quick trip to the documentation of any tool will tell you how it renders processor messages. Despite the potential differences in presentation, the nice thing about xsl:message is that it is a standard instruction and thus portable across processors. Here, I shall present several tips to make debugging with xsl:message even more effective..."

• [November 11, 2002] "Automatic Numbering, Part 1." By Bob DuCharme. From XML.com. November 06, 2002. ['The November edition of Bob DuCharme's "Transforming XML" column. In this installment, Bob digs into using <xsl:number> for adding automatic numbering to your document.'] "XSLT's xsl:number instruction makes it easy to insert a number into your result document. Its value attribute lets you name the number to insert, but if you really want to add a specific number to your result, it's much simpler to add that number as literal text. When you omit the value attribute from an xsl:value-of instruction, the XSLT processor calculates the number based on the context node's position in the source tree or among the nodes being counted through by an xsl:for-each instruction, which makes it great for automatic numbering. Eight other attributes are available to tell the XSLT processor how you want your numbers to look... Next month, we'll see how to number the different chapter, sect1, and sect2 elements as 1., 1.1, 1.1.1, and so forth, with numbering levels restarting at appropriate places. We'll also see how to number the pictures in the book automatically, both as one sequence that never restarts at '1' and also as a sequence that restarts with each new chapter..."

• [November 11, 2002] "XML Data Islands and Persistence in ASP.NET." By Rahul Guha (Senior Software Engineer, Intel e-Business Architecture Group). Intel Technical Report. November 2002. 12 pages. ['This article illustrates using persistent data islands.'] "Sometimes it's advantageous to separate data representation from the data itself, creating 'data islands.' For example, you can separate the user interface (display elements) in a XSLT file and transform the XML file (stream) through that XSLT file, which builds the HTML that is understood by browsers. A single page can access multiple data islands (such as an XML file, database source, and so forth) that each require a different XSLT file. The beauty of this design is that if you need to change any aspect of the data representation, you simply change a specific XSLT without touching the logic or main code block. This is a clean and easy way to separate presentation from data handling. Once you have data represented in the page from multiple sources of data though separate XSLTs, you may need to persist the XML data blocks (islands), make changes to the data, and save the changes in one process when the user submits the page... The Microsoft .NET Framework includes the XML Control that specifically supports data representation. Use DOMDocument (Document Object Model) to persist the data islands in the client and make changes. Submit the updated XML stream to the server where it is saved to the database. ... The example uses one Container page that includes two XML Web server controls. The controls are attached to separate XML strings, which are created from datasets filled from two separate database calls. The database calls can be to any type of data source. The XML streams are persisted in the client page in the form of hidden variables so that they can be accessed from the client-side code. Two separate XSLT files are attached to the XML controls, which are independent of each other and can incorporate any user interface elements... This solution offers the following advantages: (1) Separates the data from the presentation code, which provides flexibility. (2) Supports multiple data sources integrated into one page using the same or different presentation code. (3) Saves trips to the server every time the user makes a change. Data access is handled in one shot when the page is submitted. (4) The server processes only changed data..." [cache]

• [October 25, 2002] "Use Recursion Effectively in XSL. An Introduction to Recursion in XSL and Techniques for Optimizing Its Use." By Jared Jackson (Researcher, IBM). From IBM developerWorks, XML zone. October 2002. ['Using XSL transformations effectively and efficiently requires understanding how to use XSL as a functional language, and this means understanding recursion. This article introduces the key concepts of recursion and its particular use in XSL. Techniques for optimizing XML translations and avoiding errors while using recursion are also explained. Each concept and technique is accompanied with example code for the reader's reference.]' "Today's programming world is one dominated by imperative programming languages. All of the most popular languages -- Java technology, C (and its various flavors), Visual Basic, and others -- at a high conceptual level, work in basically the same way: You set some variables, call functions or operations that change those variables, and return the result. It is a powerful approach to programming, but it is certainly not the only one. Another breed of programming languages, while less familiar, are at least equally as powerful as their procedural counterparts. These languages are termed functional or declarative languages. Programs written in these languages may only declare variables once and can never change the value stored by a variable once it's declared. XSL as a programming language is both declarative and functional. This means that developers accustomed to writing in Java code or C and learning XSL often find themselves in foreign territory when using XSL's more advanced features. Due to the growing importance to both application and Web developers of XML and the related XSL technology, the effective use of XSL transformations cannot be ignored. Thus, it is increasingly important to learn how to program in the declarative fashion. This means becoming intimately familiar with recursion, both its basic usage and the methods for using it effectively and efficiently for the problems at hand... Once you've gained an understanding of the use of recursion, the declarative style of programming in XSL should no longer be an obstacle, but an efficient way of expanding the abilities of XML transformation. The only question remaining is which type of recursion is best for any individual situation... If your XSL engine recognizes tail recursion, then that is the best technique to use; if you cannot be assured that the transformation technology will recognize tail recursion, then the combination technique is generally preferred... Recursion can be a difficult concept to understand at first, but its usefulness and elegance becomes clearer with use..." [Sidebar: 'Is XSL a functional language?': "... Dimitre Novatchev, author and XSL developer, has written an article demonstrating how functions (templates in XSL) can indeed be passed as a data type using XML namespaces in clever manner. Whether this qualifies templates as first class data types is certainly debatable, but Novatchev's technique makes it clear that XSL can operate as a weakly-typed functional language..."]

• [October 15, 2002] "Printing from XML: An Introduction to XSL-FO." By Dave Pawson. From XML.com (October 09, 2002). ['Dave gives a straightforward primer for those wishing to start experimenting with XSL-FO to get printed pages from XML data.'] "One of the issues many users face when introduced to the production of print from XML is that of page layout. Without having the page layout right, its unlikely that much progress will be made. By way of introducing the W3C XSL Formatting Objects recommendation, I want to present a simplified approach that will enable a new user to gain a foothold with page layout. The aim of this article is to produce that first page of output -- call it the 'Hello World' program -- with enough information to allow a user to move on to more useful things. I'll introduce the most straightforward of page layouts for XSL-FO, using as few of the elements needed as I can to obtain reasonable output. One of the problems is that, unlike the production of an HTML document from an XML source using XSLT, the processing of the children of the root elements is not a simple xsl:apply-templates from within a root element. Much more initial output is required in order to enable the formatter to generate the pages... processing is a two stage process at its simplest: give your source document and the above XSLT stylesheet to an XSLT processor, and the output should be a valid XSL-FO document. This can then be fed to an XSL-FO engine -- RenderX or Antenna House (both commercial, with trial options) or to PassiveTeX or FOP (non-commercial offerings)..." See the author's book XSL-FO: Making XML Look Good in Print, published by O'Reilly in August 2002.

• [October 03, 2002] "Duplicate and Empty Elements." By Bob DuCharme. From XML.com (October 02, 2002). ['Bob DuCharme's "Transforming XML" column this month continues to guide us through our education in XSLT. In "Duplicate and Empty Elements" Bob demonstrates how to detect, delete, and create duplicate and empty elements in source and result trees.'] "Any manipulation of XML documents, whether with XSLT or not, often involves cleaning up the documents. Perhaps some company sends XML data to your company, and while it may be valid XML, it still needs to be beaten into shape a bit before your systems can use it. Dealing with duplicate elements and empty elements are typical tasks of a cleanup process. Through no fault of XSLT, finding them can be a little trickier than you might at first think, but it's not too bad, and XSLT includes several features to make these cleanup tasks go more easily... When we copy a source tree to a result tree, the task of deleting duplicate elements from the copy sounds simple: don't copy an element from the source tree to the result tree if an identical one has already been copied. But what do we mean by 'identical'? According to the XPath specification, two node sets are considered equal if their string values are equal. The string values are the concatenation of any text node descendants of the elements. Because text nodes store the character data contents of elements -- that is, the part between start- and end-tags -- two elements with different attributes or with different values in the same attribute are still considered equal, because attributes aren't taken into account in the XPath version of element equality. So, if you only want to compare element content when determining which elements are duplicates, an equals sign will do, but if you want to consider attribute values, you have to explicitly say so..."

• [October 01, 2002] "Tip: Multi-pass XSLT. Use the node-set extension to break down the XSLT operation into two or more passes." By Uche Ogbuji (Principal Consultant, Fourthought, Inc). From IBM developerWorks, XML zone. September 2002. ['Transforms can often be made cleaner and clearer if executed in phases or passes. First some intermediate output is produced, and then this is further transformed into a final output form. There can even be more than one intermediate form. In this tip, Uche Ogbuji discusses ways of breaking down XSLT operation into two or more clear passes of transformation using the common node-set extension.'] "UNIX users are very familiar with the idea of pipes -- mechanisms that direct the output of one program so that it becomes the input for another. Pipes are behind perhaps the first major examples of modularizing loosely-coupled code. Each UNIX command is very simple and targeted; complex actions are produced by stringing them together. The processing of XML using XSLT has much to gain from this same sort of modularization. You can improve code simplicity and reuse by breaking the transform into a set of separate phases or passes. Unfortunately, in pure XSLT 1.0, most of the commands for handling input of a transform are forbidden from use on output. This restriction has been removed in XSLT 2.0, and even in XSLT 1.0 (which has many more years of life) you can remove the restriction using an extension function that is usually provided by XSLT vendors... This example is an extreme simplification of a situation I encountered in a real project. I needed to reuse many DocBook processing templates on an XHTML source. By transforming XHTML content to DocBook in the first pass, and then re-using standard DocBook templates in subsequent passes, I saved a huge amount of work and debugging. The idea of multi-pass XSLT is even more general than this. In addition to promoting code reuse, it can also break complex transforms into chunks that are easy to understand. The next time you are faced with a complex problem in XSLT, determine whether it could be simplified or modularized as a series of piped operations..." Article also in PDF format.

• [August 09, 2002] "Tip: Make choices at Runtime with XSLT Parameters. Use Parameters and Conditionals in Your Style Sheets." By Nicholas Chase (President, Chase and Chase, Inc). From IBM developerWorks, XML Zone. August 2002. ['Extensible Stylesheet Langauage Transformations provide the ability to perform sophisticated manipulation of data as it is transformed from one form to another. You can increase their capabilites even further through the use of parameters that can be specified at runtime. This tip takes a basic look at using parameters and conditional statements in an XSLT style sheet. This tip uses the Xalan XSL Transformation engine, but any XSLT processor will do. It assumes that you are familiar with XSL transformations.'] "In this tip, I take a single style sheet and repurpose it to provide different results depending on the parameter values entered by the user when the document is actually transformed. The style sheet takes an XML document and transforms it into an HTML document displaying the results of a dog show. The basic style sheet creates a page with information in tables... The advantage of parameters is that you can specify them at runtime, but this capability isn't limited to transformations performed from the command line. With most engines, you can specify transformations when performing them programmatically, as well..."

• [July 11, 2002] "Integrating Data at Run Time with XSLT Style Sheets. Creating presentation markup using XML, XSLT, and the MVC design pattern." By Andre Tost (Senior Software Engineer, IBM). From IBM developerWorks, XML Zone. July 2002. ['Many applications now take advantage of XML to format business data. This allows the use of self-describing, tagged data that can be handled on a wide range of platforms and programming languages. Integration between heterogeneous applications is made easier through the use of XML data formats. Web services technology, for example, promotes the use of XML-based message formats for backend application data. However, integrating that data into user output during run time can be a challenge. In this article, Andre Tost describes how data integration can be achieved through the use of XSLT style sheets.'] "This article describes a mechanism for developing application business data and presentation data separately, and then putting them together using a generic XSLT style sheet. The application business data is formatted in XML, while the presentation data can be created with a traditional tool. The presentation data is enhanced with additional attributes that the style sheet then uses to apply presentation details to the actual content. For the creation of the final format, no special programming is necessary, as this process is completed by the XSLT processor. To get the most out of this article, you should have a basic knowledge of XML and XSLT... All the examples shown here were produced using the Apache Xerces XML parser, version 2.0.1 and the Apache Xalan XSLT processor, version 2.3.1... The solution I introduce in this article, in which application business data and presentation data are developed separately and then put together by a generic XSLT style sheet, is by no means complete; it only shows the concept. I expect that similar (but complete and robust) solutions will be developed over time. Generic style sheets like the one shown in Listing 5 can then be made available and reused where applicable. For example, the Organization for the Advancement of Structured Information Standards (OASIS) has launched the Web Services for Interactive Applications initiative [WSIA]; this initiative tries to define a component model for visual Web services, also based on the MVC pattern, which will lead to a technique similar to the one presented here..."

• [July 05, 2002] "Sorting in XSLT." By Bob DuCharme. From XML.com. July 03, 2002. ['The July 2002 "Transforming XML" column by Bob DuCharme covers sorting in XSLT.] "XSLT's xsl:sort instruction lets you sort a group of similar elements. Attributes for this element let you add details about how you want the sort done -- for example, you can sort using alphabetic or numeric ordering, sort on multiple keys, and reverse the sort order... Next month, we'll see how xsl:sort can help find the first, last, biggest, and smallest value in a document according to a certain criteria. If you can't wait, see my book XSLT Quickly, from which these columns are excerpted..." See also the ZIP file with source code.

• [June 18, 2002] "An XSL Calculator: The Math Modules of FXSL." By Dimitre Novatchev. ['This article describes the 32 functions of the latest 6 FXSL math modules'] "This article is a follow-up from three recent publications on functional programming in XSLT. Described are various new modules of the XSLT functional programming library FXSL, which implement trigonometric and hyperbolic-trigonometric, exponential and logarithmic functions and their reverse functions. Also implemented are two general methods of solving equations of one real variable. These are used within an XSLT Calculator - an interactive XSLT application driven entirely by a single stylesheet, which depends on an external object for its IO. The code of the implementation demonstrates the use of such powerful, functional programming design patterns as partial application and creation of functions dynamically... Conclusion: We described the newest 6 modules of FXSL, which implement a variety of useful math functions and two numerical methods of finding the root of a continuous function of one real variable. Their use was demonstrated through the construction of a simple yet powerful, accurate and efficient XSL Calculator. The XSL Calculator also demonstrates a reliable method of serializing a series of calls to extension functions, closely following the definition of the Monad class in Haskell." See the SourceForge project "FXSL -- the Functional Programming Library for XSLT." The FXSL functional programming library for XSLT "provides XSLT programmers with a powerful reusable set of functions and a way to implement higher-order functions and use functions as first class objects in XSLT."

• [June 06, 2002] "XML for Data. XSL Style Sheets: Push or Pull? A look at two authoring techniques for XSL style sheets and how they stack up for data." By Kevin Williams (CEO, Blue Oxide Technologies, LLC). From IBM developerWorks, XML zone. May 2002. ['Columnist Kevin Williams examines the two most common authoring styles used to create XSL style sheets: push and pull. He takes a look at some simple XML and XSL examples and discusses the benefits and drawbacks of each approach.'] "When authoring XSL style sheets, you can use either of two principal authoring styles: (1) The push style is structured around handlers that create output in the output document. The output is based on the type of elements encountered in the source document. Element content is pushed to the appropriate handler. (2) The pull style, on the other hand, builds up the output document by pulling content from the source document as it is needed. The style you choose has a significant impact on the code complexity and maintainability of your style sheets... A data document is intrinsically different from a narrative document in that: (1) Information in a data document appears in an order that can be anticipated in the code. (2) A data document contains no loose text, so no specialized code is required to transfer that text to the output document. Mapping a source data document to a output document usually is no more complex than renaming elements, reordering them, and aggregating them up a level in the target tree (or pushing them down to a more detailed level). If you use the pull model, the mapping is simple and easy to maintain. On the other hand, documents that are narrative-based are exactly the opposite. Information appears in an order that cannot be anticipated easily; some text floats outside of the context of elements so it needs to be moved over to the output document properly. To accurately reproduce the narrative in the output document, the style sheet must handle elements regardless of where they appear, and the push model excels at that. In short, when designing style sheets for data documents, consider using the pull model first. For narrative documents, use the push model if possible. Becoming proficient at writing both kinds of style sheets -- and learning the strengths and weaknesses of each -- will enable you to handle any styling job you might encounter in the future..."

• [May 03, 2002] "Splitting and Manipulating Strings." By Bob DuCharme. From XML.com. May 01, 2002. ['In his monthly column on XSLT, "Transforming XML," Bob DuCharme focuses on using XSLT to manipulate strings, and as ever relishes the opportunity to talk about poetry and wine on XML.com.'] XSLT is a language for manipulating XML documents, and XML documents are text. When you're manipulating text, functions for searching strings and pulling out substrings are indispensable for rearranging documents to create new documents. The XPath string functions incorporated by XSLT give you a lot of power when you're manipulating element character data, attribute values, and any other strings of text that your stylesheet can access. We'll start by looking at ways to use these functions to split up strings and how a PCDATA element might be split into subelements. [...] Next month, we'll look at how to compare two elements to see if they're the same. We'll also look at a way to implement a global string replace with an XSLT stylesheet."

• [April 18, 2002] "Expand XSL with Extensions. Technique Helps Expand the Capabilities of XSL's Core Features." By Jared Jackson (Research Associate, IBM). From IBM developerWorks, XML Zone. ['The combined power of XML and XSL for representing, manipulating, and presenting data over the Web and sharing data across differing applications has been clearly demonstrated through the fast acceptance and broad usage of these technologies. Still, most developers familiar with the basics of XML and XSL are not utilizing this power fully. This article shows developers how to use extensions, a technique that allows you to expand the capabilities of XSL.'] "In terms both of power and simplicity, the combination of XML and XSL has revolutionized data storage and manipulation in a way not seen since the early days of the SQL database language. XML provides a clear and independent way of recoding data that is easily shared and understood. Similarly, many people feel that XSL is also easy to read, write, and understand. Clearly, this powerful duo are essential knowledge for everyone involved in the technology industry. The broad scope and small learning curve associated with the basic elements of XSL transformation sometimes acts as a double-edged sword -- yielding broad usage of the core technology but dissuading the majority of developers learning XSL from investigating and using its more advanced and powerful features. This article is written for developers who already have a basic understanding of XML and XSL, and are ready to build on this knowledge. If you are unfamiliar with these technologies, you can find several good introductory articles and tutorials on developerWorks and other Web sites. The article shows you how to use extensions -- a technique present in most XSL processors -- which allows virtually unlimited expansion of the existing capabilities of XSL's core features. This article includes a general description of how to write extensions with code, followed by three specific and widely applicable examples... Even when considering the most basic components of XSL transformations, their capabilities are remarkable. When this core is extended with extensions to encompass the power of modern programming languages, the possibilities become virtually limitless. The ideas and examples presented above are but the tip of the iceberg, and I leave it to you, after gaining an undestanding of what is presented here, to explore the many remaining possibilites."

• [April 12, 2002] "What's New in XSLT 2.0?" Part 2. By Evan Lenz. From XML.com. April 10, 2002. ['Interest is strong in the W3C's development of XSLT 2.0. In a follow-up to his previous article on XPath 2.0, Evan Lenz describes the powerful new features proposed by the W3C for XSLT 2.0, which bring more convenient solutions to many of the bugbears involved with working with XSLT 1.0.'] "In my previous article, I went through a brief overview of some of the features that XPath 2.0 offers over and above XPath 1.0. We saw that XPath 2.0 represents a significant increase in functionality for XSLT users. In this article, we'll take a look at some of the new features specific to XSLT 2.0, as outlined in the latest working draft. Again, this assumes that you are familiar with the basics of XSLT/XPath 1.0. XSLT 2.0 goes hand in hand with XPath 2.0. The two languages are specified separately and have separate requirements documents only because XPath 2.0 is also meant to be used in contexts other than XSLT, such as XQuery 1.0. But for the purposes of XSLT users, the two are linked together. You can't use XPath 2.0 with XSLT 1.0 or XPath 1.0 with XSLT 2.0. At least, the W3C is not currently proposing any such combination... XSLT 2.0 includes a number of other useful features that we won't go into detail here. They include a mechanism for defining a default namespace for XPath expressions, the ability to use variables in match pattern predicates, named sort specifications, the ability to read external files as unparsed text, and so on. In addition, a large part of the XSLT 2.0 specification remains to be written, particularly the material dealing with the construction and copying of W3C XML Schema-typed content... For those of you who can't wait to start trying some of this stuff out, Michael Kay has released Saxon 7.0, which includes an 'experimental implementation of XSLT 2.0 and XPath 2.0'. It implements a number of features in the XSLT 2.0 and XPath 2.0 working drafts, with particular attention to those features that are likely the most stable. I've tested each of the examples in this article, and Saxon 7.0 executes them all as expected..."

• [April 11, 2002] "XSLT." By Elliotte Rusty Harold. Notice posted to XML-DEV 2002-04-11. Chapter 17 of Processig XML with Java. This work is being written as "a complete tutorial about writing Java programs that read and write XML documents. It will become an approximately 700 page book that will be published by Addison-Wesley in Spring 2002... This chapter includes three major sections: (1) A brief XSLT tutorial (2) Detailed discussion of the TrAX API for using XSLT with Java (3) Writing XSLT extension functions and elements in Java I'm particularly pleased with the first section. I've written several XSLT tutorials before, but this one is radically different. It considers XSLT primarily as a functional programming language and focuses on the ability to call templates recursively. I doubt there's anything here that hasn't been discovered or invented by someone somewhere before, but certainly I had never seen some of the things you could do with XSLT until I invented them for this chapter. I wouldn't recommend this as your first exposure to XSLT (see instead "XSL Transformations" in XML Bible, Gold Edition) but if you're already familiar with XSLT basics, this chapter may show you a few new tricks..."

• [April 11, 2002] "Practical Formatting Using XSLFO. (Extensible Stylesheet Language Formatting Objects.)" By G. Ken Holman. Second Edition. 2002-04-05. ISBN 1-894049-09-8. From Crane Softwrights Ltd. 361 pages, free 175-page download preview excerpt. "This revised Second Edition again contains all formatting objects of the W3C XSLFO 1.0 Recommendation with additional text, examples, twice as many diagrams, and new content based on feedback and requests for additions from existing customers. It has been four months since the last edition. The free download preview excerpt (in both A4 and US-letter page sizes) has also been updated to reflect the content of the new edition. If you have downloaded the earlier free preview excerpt, you may wish to pick up a new copy..."

• [April 05, 2002] "Putting Attributes to Work." By Bob DuCharme. From XML.com. April 03, 2002. ['Bob DuCharme's "Transforming XML" column this month looks at the many ways that attributes from a source XML document can be processed in XSLT.'] "Once an XML document is read into a source tree, where an XSLT stylesheet can get a hold of it, there's a lot that the stylesheet can do with the source document's attribute values. This month we'll look at how to convert attributes to result tree elements, how to grab attribute values for more general use, how to test attribute values for specific values, and how to define groups of attributes for easier re-use in multiple places in the result tree... Attributes can play a role in almost any aspect of XSLT development, and this column has outlined just a few of the ways to take advantage of them. See my book XSLT Quickly for even more on ways to take advantage of attribute values in your source documents..."

• [March 29, 2002] "Template Languages in XSLT." By Jason Diamond. From XML.com. March 27, 2002. ['Our main feature this week on XML.com takes up where Eric van der Vlist left off in his July 2000 article on "Style Free Stylesheets." Jason Diamond follows up on Eric's observations that XSLT doesn't encourage a good separation between content and presentation, and pursues the development of a higher-level templating language aimed at creating a cleaner XSLT template infrastructure. Jason shows how his example-based template language, implemented in XSLT itself, is easier for everyday use, especially where non-technical colleagues are involved.'] "Despite its simplicity and its original purpose, XSLT is an extremely rich and powerful programming language. Just about anything that can be done with XML can be implemented in XSLT -- all it really takes is a little bit of creativity and a whole lot of pointy brackets. One of the most common uses of XSLT is to transform XML content into something more suitable for viewing. This separation between content and presentation seems to be the most often cited advantage for many XML advocates. XSLT was designed specifically for this task It could be argued, however, that, XSLT fails miserably at separating these two layers. Traversing source documents with any sort of XPath or XSLT instructions like xsl:for-each and xsl:apply-templates in your style sheets is like opening a connection to a database and performing a query in the middle of an ASP or JSP page. Good programmers don't do this because it breaks the separation between the presentation and data tiers in their applications. Thinking about it from an altogether different perspective, having literal result elements interspersed with XSLT instructions in your transforms is like generating HTML by concatenating strings and then printing them to your output (as is often done when implementing servlets). Most designers can't work in an environment like that. Even if they can, they shouldn't have to concern themselves with all the logic of extracting and manipulating the data they're trying to present... Getting XSLT to process your custom templates isn't as easy as I would like it to be, but once the initial framework is created, adding new instructions and variables is relatively painless. Creating a prototype with XSLT is certainly the quickest way to go as you can easily add new instructions when your template designer needs them. I've personally used the techniques described in this article to prototype a template language with close to 200 instructions. The templates that utilized those instructions were still preferable to hardcoded XPath/XSLT, and it was possible to re-implement the template language processor in a more efficient language (a subject for another article) once the design was finalized without requiring any changes to the templates themselves..."

• [March 22, 2002] "What is XSL-FO?" By G. Ken Holman. From XML.com. March 20, 2002. ['In an extended excerpt from his renowned training materials, Ken Holman explains the W3C's XSL Formatting Objects technology, XSL-FO, intended to facilitate page-based formatting of XML documents. Ken introduces XSL-FO's basic concepts and processing model, and places it in the context of XML and XSLT. Including plenty of examples and diagrams, "What is XSL-FO?" should give you a good grounding and leave you ready to start experimenting with this exciting technology.'] "Crane Softwrights Ltd. has published Practical Formatting Using XSLFO covering every formatting object of XSLFO and their properties, according to the final XSL 1.0 Recommendation of October 15, 2001. The first two chapters of this book have been rewritten in prose and are made available here as an introduction to the technology and its use. This material assumes no prior knowledge of XSLFO and guides the reader through background, context, structure, concepts, introductory terminology, and a short introduction of each of the formatting objects. Note that neither the Recommendation itself, nor Crane's training material, attempt to teach facets of typography and attractive or appropriate layout style, only the semantics of formatting, the implementation of those semantics, and the nuances of control available to the stylesheet writer and implemented by the stylesheet formatting tool. XSLFO is a very powerful language with which we can possibly create very ugly or very beautiful pages from our XML-based information... Two vocabularies specified in separate W3C Recommendations provide for the two distinct styling processes of transforming and rendering XML instances. The Extensible Stylesheet Language Transformations (XSLT) is a templating markup language used to express how a processor creates a transformed result from an instance of XML information. The Extensible Stylesheet Language Formatting Objects (XSLFO) is a pagination markup language describing a rendering vocabulary capturing the semantics of formatting information for paginated presentation. Formally named Extensible Stylesheet Language (XSL), this Recommendation normatively incorporates the entire XSLT Recommendation by reference and, historically, used to be defined together in a single W3C draft Recommendation..." See also the two "how-to" articles of J. David Eisenberg on XSL-FO, published last year: [1], [2].

• [February 07, 2002] "The Functional Programming Language XSLT. A Proof Through Examples." By Dimitre Novatchev. November, 2001. "Until now it was believed that although XSLT is based on functional programming ideas, it is not as yet a full functional programming language, as it lacks the ability to treat functions as a first-class data type. Based on numerous concrete XSLT implementations of some of the major functional programming design patterns, including some of the most generic list-processing and tree-processing functions, this article provides ample proof that XSLT is in fact a full-pledged functional programming language. The presented code forms the base of a first XSLT functional programming library. It is emphasized that a decision to include higher-order functions support in XPath 2.0 will make functional programming in XSLT even more straightforward, natural and convenient... ... The purpose of this article is not only to prove that XSLT can be considered a functional programming language has been fulfilled by providing XSLT implementation for the most major FP design patterns and examples from John Hughes article 'Why Functional Programming matters' (this article contains the code of 35 functions), but as a side effect we have now available what can be considered the first XSLT functional programming library. The full library code, together with test examples demonstrating the use of individual functions, is available at the downloads page of TopXML.COM as specified in the links at the start of this article... "On the other side, the XSLT code of those functions seems too-verbose compared to the corresponding Haskell code. The process of writing functional XSLT code can be made much more straightforward and easier by providing support for higher-order functions in XPath and XSLT, thus definitely improving even further the compactness, readability and reliability of XSLT functional code. It is the ideal time right now for the W3C XPath 2.0 working group to make the decision to provide the necessary support for higher-order functions as part of the standard XPath 2.0 specification. In case this golden opportunity is missed, then generic templates and libraries will be used in the years to come." Download the full PDF (.ZIP) version.

• [February 07, 2002] "Declaring Keys and Performing Lookups." By Bob DuCharme. From XML.com. February 06, 2002. ['DuCharme returns this week with his monthly XSLT column, "Transforming XML." This time Bob explains the use of XSLT's keys mechanism, which can used for fast lookup of information during stylesheet processing.'] "When you need to look up values based on some other value -- especially when your stylesheet needs to do it a lot -- XSLT's xsl:key instruction and key() function work together to make it easy. They can also make it fast. To really appreciate the use of keys in XSLT, however, let's first look at one way to solve this problem without them. Let's say we want to add information about the shirt elements in the following document to the result tree, with the color names instead of the color codes in the result..."

• [January 22, 2002] "XSL Formatting Objects: Here Today, Huge Tomorrow." By Frank Neugebauer. In XML-Journal Volume 3, Issue 01 (January 2002). "There are two parts to the W3C Recommendation: a transformation part (XSLT) and a formatting part (XSL Formatting Objects, or XSL-FO for short) with the intent being the presentation of XML. However, since XSLT is also its own (more mature) W3C Recommendation, it has enjoyed the attention of developers wishing to transform XML into other markup languages such as HTML. In a very real sense XSLT is how XML is currently being visually presented. Although using XSLT to transform XML to HTML can be very powerful and useful, it also has some serious limitations. For example, HTML, even when combined with Cascading Style Sheets (CSS), can cause unpredictable results when printing. Another limitation is the need for developers to understand the inner workings of the expected eventual output format(s) (e.g., HTML, WML) and to code XSL Stylesheets for each such output format expected. In theory (and partially in practice), XSL Formatting Objects can overcome these shortcomings because the language is a kind of "general" markup language with extensive formatting capabilities without being output format-specific. It may eventually be positioned as the ultimate language for expressing the output format of XML documents across software (e.g., Web browsers, word processors) and hardware (e.g., printers, cell phones) boundaries. Admittedly this speculation is a bit optimistic - the result of the promise brought about by the growing maturity and capability of XSL-FO processors. Currently, a number of maturing XSL-FO processors are capable of rendering such formats as Portable Document Format (PDF), Rich Text Format (RTF), and plaintext, among others... In this article I'll use a demo version of one such processor, RenderX's (www.renderx.com ) XEP, to demonstrate how XSL-FOs work in the hopes of providing you with the same "enlightenment" I experienced when I first started using XSL-FO..."

• [November 29, 2001] "XML Transformation Flow Processing." By Jérôme Euzenat (INRIA Rhône-Alpes) and Laurent Tardif (Monash University). In Proceedings of the Second Extreme Markup Languages Conference, Montréal, Canada, August, 2001. Pages 61-72. "XML has stimulated the publication of open and structured data. Because these documents are exchanged across software and organizations, they need to be transformed in many ways. For that purpose, XSLT allows the development of complex transformations that are adapted to the XML structure. However, the XSLT language is both complex in simple cases (such as attribute renaming or element hiding) and restricted in complex cases (complex information flows require processing multiple stylesheets). We propose a framework which improves on XSLT by providing simple-to-use and easy-to-analyse macros for common basic transformation tasks. It also provides a superstructure for composing multiple stylesheets, with multiple input and output documents, in ways not accessible within XSLT. Having the whole transformation description in an integrated format allows better control and analysis of the complete transformation... [Conclusion:] We have presented the Transmorpher system and principles which aim at complementing XSLT on the issue of simple transformations and complex control of transformations. It tries to implement for transformations, the slogan 'Make simple things easy and complex ones possible'. Although only limited experiments have been conducted with the system it behaves the way it was intended. The concepts that have been proposed in this paper are viable ones and overcome some limitations of XSLT (more generally, of stand-alone one-pass template-only transformation systems). As Cocoon demonstrates, Transmorpher corresponds to a real need and we expect to see more systems of its kind in the next few years. The bibliography example is a real example available from our web site. Transmorpher has not been designed for efficiency but for intelligibility: Our ultimate goal is to offer an environment in which we will be able to certify that a particular output of a compound transformation satisfies some property (e.g., hiding some type of information, preserving order, or preserving 'meaning'). Another good property of intelligibility (through modularity) is that it is easy to imagine a graphical user interface to Transmorpher."

• [January 07, 2002] "Controlling Whitespace, Part Three." By Bob DuCharme. From XML.com. January 02, 2002. ['Bob DuCharme's XSLT column, Transforming XML, progresses to the third and final part of its look at controlling whitespace in XML. This month's edition shows how to add tabs and indentation to the output of an XSLT transformation.'] "In the first and second parts of this three-part series, we looked at techniques for stripping, processing, and adding whitespace when creating a result document from a source document. This month we'll see how to add tab characters to a result document, and how to automate the indenting of a result document according to the nesting of its elements... an indent value of 'yes' is useful if every element in your source document has either character data and no elements as content or elements and no character data as content; but it can lead to unpredictability if your source document has elements that mix child elements with character data..."

• [November 08, 2001] "Controlling Whitespace, Part 1." By Bob DuCharme. From XML.com. November 07, 2001. ['DuCharme shows how to strip and preserve whitespace with XSLT.'] "XML considers four characters to be whitespace: the carriage return, the linefeed, the tab, and the spacebar space. Microsoft operating systems put both a carriage return and a linefeed at the end of each line of a text file, and people usually refer to the combination as the 'carriage return'. XSLT stylesheet developers often get frustrated over the whitespace that shows up in their result documents -- sometimes there's more than they wanted, sometimes there's less, and sometimes it's in the wrong place. Over the next few columns, we'll discuss how XML and XSLT treat whitespace to gain a better understanding of what can happen, and we'll look at some techniques for controlling how an XSLT processor adds whitespace to the result document... when you're using XSLT to create XML documents, you shouldn't worry too much about whitespace. When using it to create text documents whose whitespace isn't coming out the way you want, remember that XSLT is a transformation language, not a formatting language, and some other tool may be necessary to give you the control you need. Extension functions may also provide relief; string manipulation is one of the most popular reasons for writing these functions..."

• [November 01, 2001] "How to Develop Stylesheets for XML to XSL-FO Transformation." From Antenna House. 2001-10-24. "The 63 page tutorial developed by Antenna House, Inc. for customers of XSL Formatter is [here] made public. This is not only useful for better understanding of XSL and XSLT but also this may be used as a practical sample of XML and XSLT stylesheet. The source file is an XML document based on "sampledoc.dtd"; the source XML file; the XSLT Stylesheet to transform the source XML file to XSL formatting objects tree. PDF versions are available. They is formatted from the source XML and XSLT Stylesheet by XSL Formatter and printed to PDF file using Acrobat..." See the reference page and complete set of source file including graphics files. W3C note: "it conforms only to the XSL 1.0 CR, but the differences between CR and Rec are minor." [cache]

• [August 31, 2001]   XPathLog and LoPiX: a Logical Approach to XML and XML Data Integration.    Researchers at the Institut für Informatik, Universität Freiburg are developing XPathLog/LoPiX project as a continuation and migration of F-Logic/Florid to XML. The LoPiX system "is an implementation of the XML querying and data manipulation language XPathLog; it is free for evaluation, research and teaching purposes. XPathLogic is a logic which is interpreted with respect to XML documents. Its Horn fragment, XPathLog, provides a logic-based language for manipulating and integrating XML data. Due to many similarities between the F-Logic and XPath languages, F-Logic is a natural candidate for a migration to XML/XPath: The XPathLog language is a crossbreed between XPath and F-Logic, i.e., it extends XPath with variable bindings to an XML querying and data manipulation language. XPathLog assigns a declarative constructive semantics to XPath expressions for specifying database updates. The LoPiX system which implements XPathLog is based on the Florid system. The research on data integration is now continued with LoPiX. One of the main results -- apart from the fact that XPathLog/LoPiX is the first implementation of updates in an XML database language, is that the DOM/XML Query Data Model is not suitable for updating and integrating XML data. Instead, XPathLog/LoPiX use the XTreeGraph data model which allows for representing multiple, overlapping XML trees in an internal database. Result trees are then defined as views over the XTreeGraph database." [Full context]

• [August 31, 2001] "Top Ten Java and XSLT Tips." By Eric M. Burke. From O'Reilly Java News. 29 August 2001. "My new book, Java and XSLT, examines techniques for using XSLT with Java (of course!). This article highlights ten tips that I feel are important, although limiting the list to ten items only scratches the surface of what is possible. Most of these tips focus on the combination of Java and XSLT, rather than on specific XSLT (Extensible Stylesheet Transformations) techniques. For more detailed information, there are pointers to other valuable resources at the end of this article. The basics of XSL transformations are pretty simple: one or more XSLT stylesheets contain instructions that define how to transform XML data into some other format. XSLT processors do the actual transformations; Sun Microsystems' Java API for XML Processing (JAXP) provides a standard Java interface to various processors. Here is some sample code that performs an XSL transformation using the JAXP API... XSLT is not a difficult language, although it does work quite differently than Java. Diving in and writing stylesheets is probably the best way to get over the initial learning curve." You can download some sample code that performs an XSL transformation using the JAXP API; the .ZIP file contains the example, along with an XSLT stylesheet and XML data file. The included README file explains how to compile and run the example. Although the example utilizes StreamSource to read data from files, JAXP can also read XML data from SAX parsers or DOM trees... Tip #1: Cache whenever possible: Performing transformations using XSLT is CPU- and memory-intensive, so it makes sense to optimize whenever possible. Various caching techniques are one of the best ways to improve runtime performance in XSLT-driven Web applications...."

• [August 15, 2001]   Java XPath Engine 'Jaxen' Supports XPath Expression Evaluation via JDOM, dom4j, EXML, and W3C-DOM.    A posting from Bob McWhirter announces the availability of Jaxen Version 1.0-beta-4. With development hosted on SourceForge, the Jaxen project is developing a Java XPath Engine. Jaxen is "a universal object model walker, capable of evaluating XPath expressions across multiple models." The current version provides support for parsing and evaluating XPath expressions against JDOM, dom4j, EXML, and W3C-DOM documents. Beta version 4 has better public API for each support model, and includes numerous bugfixes. According to the developers' description, "Jaxen itself is based upon SAXPath, which is an event-based model for parsing XPath expressions. Since Jaxen works against an adaptor which provides InfoSet access to arbitrary object models, it should be possible to build even larger tools in terms of Jaxen, to work with multiple models. For example, an XQL engine could be developed, which would automagically work with all models already supported by Jaxen. Jaxen may be perceived to be better than other XPath technologies since it provides a single cohesive API for evaluating XPaths against multiple object models. Learn the Jaxen API, and apply it to dom4j, JDOM, EXML or DOM trees in exactly the same way..." [Full context]

• [August 13, 2001] "Getting Loopy. [Transforming XML.]" By Bob DuCharme. From XML.com. August 01, 2001. "Programming languages use loops to execute an action or series of actions multiple times. After performing the last action of such a series, the program 'loops' back up to the first one. It may repeat these actions a specific number of times -- for example, five times or thirty times. It may repeat the actions until a specified condition is true -- for example, until there's no more input to read or until a prime number greater than a million has been calculated. XSLT offers two ways to repeat a series of actions... (1) The xsl:for-each instruction lets you perform a group of instructions on a given set of nodes. The specification of those nodes can take full advantage of the options offered by XPath's axis specifiers, node tests, and predicate conditions; (2) By having a named template call itself recursively with parameters, you can execute a series of instructions for a fixed number of times or until a given condition is true. This technique comes from one of XSLT's ancestors, LISP, a programming language developed for artificial intelligence work in the 1960s..."

• [August 02, 2001] "XMLegant Answers: 'T' is for 'Transformation'." By Bill Trippe. In Transform Magazine August 2001. "People often ask me, 'What's the big deal about XML?' On its own, XML data just sits there - tidy, well organized and self-describing - but it still just sits there. Yet XML is an expanding technology not for what it does itself; it is important because of the many related technologies and standards now coming to light. At the very least, you need to be able to format data for presentation and shape it into any other necessary forms. This is where Extensible Stylesheet Language (XSL) comes in, and, in particular, its offshoot language, XSL Transformations (XSLT). This talk of transformation probably seems self-serving - this magazine is named Transform, after all. But, in fact, the word "transformation" has been used with XML since its inception and earlier than that with SGML, XML's predecessor. The question about XML data always has been, 'What can I do with it?' The first answer has always been, 'Transform it into something else.' In my June column, I talked about XML schemas and how they are central to data modeling in the new enterprise infrastructure. One of my key points in that column was that software development today often involves moving data among loosely coupled systems, and the schema becomes the lynchpin in this movement. If schemas are the lynchpin, XSLT and other transformation tools are both the intermodal transportation system - how the data gets from one unlike system to another - and the machinery for moving all the data at each point... The concepts are pretty straightforward. XML data can be traversed, among other ways, as a tree structure. For instance, you can think of an address database as one big tree, with each address being a branch, and elements of each address being smaller branches, and so on. In this example, you could use XSLT to traverse the addresses to select and manipulate each name and phone number, or each name and ZIP code, or each name, phone number and ZIP code. If you have multiple databases with such information, you could create XML versions of the data and use XSLT to map from one data source to another..."

• [August 01, 2001] "A Framework for Multilingual, Device-Independent Web Sites. Using Sun XML Language and Device-Independent JSP Extensions to Implement Dynamic Web Content" By Marc Hadley (Staff Engineer, Sun Microsystems). April, 2001; posted July 2001. ['Get a thorough introduction to using Sun XML Language and Device- Independent JSP Extensions to implement dynamic, multi-lingual, platform-independent Web content. Includes sample code.'] "The main problem with HTML, WML and and other presentation based markup languages is that the content is intermingled with the presentation in such a way that it is difficult to extricate one from the other. The eXtensible Markup Language (XML) solves this problem by providing a standard for the semantic markup of content along with a standard way, XSL Transformations (XSLT), to transform XML to presentation oriented delivery formats... Java Server Pages (JSP) provide an ideal platform for dynamic page generation. In particular JSP 1.1 Tag Extensions, also called custom tag libraries or taglibs for short, provide a simple way to encapsulate such functionality in an easy to use tag based form... The Sun XML Language and Device-Independent JSP Extensions (XML LDI Extensions) are a set of JSP tag extensions useful for creating multi-lingual and device-independent web pages. XML LDI Extensions are available in both binary and source code distributions and are released under the corresponding Sun License. Readers are assumed to have a passing familiarity with XML and to be comfortable programming JSP pages. Installation instructions for the Sun XML Language and Device-Independent JSP Extensions can be found online. ... JSP custom tag extensions provide a convenient and easy to use method of incorporating dynamic content in web pages. The combination of XML and context sensitive XSLT allows development of device independent web pages. Pages can be made multilingual by ensuring that XSLT stylesheets are language independent through the use of vocabulary repositories..." See other Sun XML Resources on the web site.

• [July 18, 2001] "XML Transformation Demo. With Apache, mod_perl, and AxKit." By Chuck Bearden (Rice University). ['XML files are three finding aids for collections in Fondren Library's Woodson Research Center, marked up in EAD.] "By way of follow-up to [discussion] about AxKit, I'm posting the link to a brief demo of XSLT transformation I created for an introductory XML course given by a colleague here at Rice... I use three finding aids from collections in our Woodson Research Collection, marked up in EAD as part of the TARO project. There are links permitting you to view them as plain XML (mime type 'text/plain'), and transformed according to each of five XSLT stylesheets. Let me emphasize that I don't know XSLT. Daniel Pitti of IATH at UVa created these stylesheets for use in the courses he teaches, and he kindly sent them to me for the purposes of creating this demo. These stylesheets were not designed for transforming EAD into HTML for public use on websites, but rather for illustrating XSLT transformation pedagogically. My demo is designed to show folks new to XML how one document source can be transformed into multiple outputs--something which readers of this list are well aware of. However, it also lets you see AxKit with libxml2 and libxslt at work..." See "Encoded Archival Description (EAD)."

• [July 16, 2001] Do you XML? Then you need to XSL." By Bill Pitzer. In ZDNET Developer July 09, 2001. "XML might carry alot of promise among today's Web developers, yet until very recently it offered little control over its mode of presentation: introducing XSL. XML has definitely been the buzz around the Web development world, especially following the release of Internet Explorer 5, with its updated XML parser. But while XML is great for describing structured data, it doesn't actually have a means of displaying the data that it describes. XML was designed this way so that data is kept separate from its presentation. Enter Internet Explorer 5 again, which now supports a subset of the Extensible Stylesheet Language, or XSL. XSL transformations turn XML into a grammar and structure suitable for display in a browser. Internet Explorer 5 supports many different types of XSL transformations. A complete listing can be found in the "XSL Developer's Guide" on Microsoft's site. In this article, we'll concentrate on applying XSL style sheets to XML documents. This allows direct browsing of the XML data contained in your page. Although Cascading Style Sheets (CSS) can be used for this purpose, they don't provide the flexibility allowed by XSL. ... This simple example barely scratches the surface of what can be done with XML. The language is a very powerful tool for manipulating data. Look more closely at the XSL reference and you'll see how easy it is to change the look of your output. Using this article as a starting point, take our structure and try to tweak it. Some things you could try: sort the records, filter them on certain field criteria, or actually change the data in a node before outputting it. XML's strength will become more apparent as you become more familiar with the language and its application. And, keep in mind that the transformation method we use in this article is a subset of the entire XSL language working draft. Microsoft intends to support XSL in its entirety, based on the final W3C recommendations..."

• [July 05, 2001] "Transforming XML: Math and XSLT." By Bob DuCharme. From XML.com. July 05, 2001. ['XSLT is primarily for transforming text, but you can use it to do basic math too.'] "XSLT's full support of XPath's math capabilities lets you do all the basic kinds of arithmetic and a little more. Let's look at a stylesheet that demonstrates these capabilities by using the values from this document... XSLT is about manipulating text, not numbers, but you can build on the mathematical operations provided as part of XSLT to perform more complicated calculations. For example, the following stylesheet, which accepts any document as input, computes the value of pi. The precision of the result depends on the value of the iterations variable..."

• [June 19, 2001] "XML Training Wheels. An XSLT and Java-based tool for producing tutorials -- custom-built for developerWorks but ready to adapt to your own use." By Doug Tidwell (Cyber evangelist, developerWorks). From IBM developerWorks. June 2001. ['See how developerWorks produced a custom XSLT application with Java-based open-source tools that automates the tedious work of producing the developerWorks HTML-based tutorials. Known as the Toot-O-Matic, the tool now is available for any developer either to inspect as an XSLT exemplar or to tailor to your own training needs. Doug Tidwell explains the design goals and the XML document design. He also describes how the 13 code samples demonstrate the techniques used in generating a truckload of HTML panels full of custom graphics, a ZIP file, and two PDF files from a single XML source document.'] "Here at developerWorks, we're pleased to release the source of the Toot-O-Matic, the XML-based tool we use to create our tutorials. In this article, we'll discuss the design decisions we made when we built the tool, talk about how you can use it to write your very own tutorials, and talk a little bit about how the source code is structured. We hope you find the tool useful, and that it will give you some ideas about how to use XML and XSLT style sheets to manipulate structured data in a variety of useful ways... In achieving the final goal of seeing how much we could do with XSLT, the Toot-O-Matic exercises all of the advanced capabilities of XSLT, including multiple input files, multiple output files, and extension functions. Through the style sheets, it converts a single XML document into: (1) A web of interlinked HTML documents; (2) A menu for the entire tutorial; (3) A table of contents for each section of the tutorial; (4) JPEG graphics containing the title text of all sections and the tutorial itself; (5) A letter-sized PDF file; (6) An A4-sized PDF file; (7) A ZIP file containing everything a user needs to run the tutorial on their machine... This discussion of the Toot-O-Matic tool illustrates the full range of outputs that you can generate from a single XML file. The structure of our original XML documents enables us to convert flat textual information into a number of different formats, all of which work together to deliver a single piece of content in a variety of interesting and useful ways. Using this tool, we have shortened and streamlined our development process, making it easier, faster, and cheaper to produce our tutorials. Best of all, everything we've described here is based on open standards and works on any Java-enabled platform. The Toot-O-Matic tool shows how a simple, inexpensive development project can deliver significant results." Also available in PDF format. [cache]

• [June 19, 2001] "Style sheets can write style sheets too. Making XSLT style sheets from XSLT components." By Alan Knox (Software Engineer, IBM, Hursley Park, Hampshire, England). From IBM developerWorks. June 2001. ['XSLT style sheets can be used to dynamically transform XML to complex presentation markup for browsers -- but if the presentation is complex, the style sheet will be too. What's needed is some tool that can build complex style sheets from simple components. Since XSLT is itself an XML, XSLT can be manipulated with XSLT; style sheets can write style sheets. This article shows how an XSLT style sheet that performs some particular runtime transformation can be built from XSLT components.'] "Another developerWorks article, 'Spinning your XML for screens of all sizes,' discusses problems with writing and managing style sheets that present the same XML basketball statistics on many display devices. The solution involved writing a parameterized style sheet that produces HTML with varying degrees of data content, and then transcoding the output from that style sheet for a specific device using WebSphere Transcoding Publisher. This is an effective and easy solution for many scenarios, but you lose some control over what appears on a user's screen. If you want: (1) Absolute control over what users see, (2) To tune presentation of your application to give the best possible experience on each device, (3) To make use of particular features of a device... Then you have to solve the problems of generating numerous, complex style sheets. This article demonstrates a no-compromise solution that uses the same basketball XML data... XSLT is a declarative language, where the templates that make up a style sheet are independent of each other. XSLT style sheets can be composed from other style sheets using the import and include mechanisms. With suitable care, you can independently develop a number of separate component style sheets that can be put together to make the presentation style sheet that will be applied to the XML data at runtime. These components will be broadly of three types, that deal with: Presenting dynamic XML data [the basketball data in my example]; Reusable bits of presentation mark-up, such as button bars; The residue of the page..." Article also available in PDF format.

• [June 11, 2001] "Transforming XML: Using the W3C XSLT Specification." By Bob DuCharme. From XML.com. June 6, 2001. ['For advanced XSLT use, the W3C's XSLT specification can be a handy tool. This guide helps you read the specification and clears up confusing terms.'] "The W3C's XSLT Recommendation (available at http://www.w3.org/TR/xslt) is a specification describing the XSLT language and the responsibilities of XSLT processors. If you're new to XSLT, the Recommendation can be difficult to read, especially if you're not familiar with W3C specifications in general and the XML, XPath, and Namespaces specs in particular. This month, I'd like to summarize some of the concepts and terms that are most likely to confuse an XSLT novice reading the XSLT Recommendation..."

• [May 05, 2001] "Transforming XML: Namespaces and Stylesheet Logic." By Bob DuCharme. From XML.com. May 02, 2001. ['In the second part of a two-part series on handling XML Namespaces, Bob explains how to process namespaces in a source document, and gives an example of processing XLink into HTML.'] "In last month's 'Transforming XML' column, we saw how to control the namespaces that are declared and referenced in your result document. If your stylesheet needs to know details about which namespaces are used in your source document, and to perform tasks based on which namespaces certain elements or attributes belong to, XSLT offers a variety of ways to find out. This month we look at them. To experiment, we'll use the following document. It has one title element and one verse element from the http://www.snee.com/red namespace, two verse elements from the http://www.snee.com/blue namespace, and one verse element from the default namespace... XSLT's ability to base processing logic on namespace values makes it a great tool for developing XLink applications. As you use XSLT to process more and more XML documents with elements from specialized namespaces -- for example, SOAP envelopes, XHTML elements, or XSL formatting objects -- you'll find these techniques invaluable for keeping track of which elements come from where so that you can take the appropriate action with them." [Sample documents and stylesheets are available in the zip file.]

• [April 24, 2001] "Sun IPR statement on XPointer." [Submitted to W3C by Eve L. Maler.] Posted to XML-DEV 2001-04-24. Excerpt: "This policy shall apply only to Sun's Essential Patent Claims (as defined below) that read on the XML Pointer Language specification ('XPointer'). This undertaking is valid only as long as XPointer either is on the Recommendation track or has been adopted as a Recommendation. Sun Microsystems, Inc. ('Sun') agrees it will grant royalty-free licenses, under reasonable terms and conditions, and on a non-discriminatory basis, under Sun's essential patent claims to make, use, sell, offer for sale, or import implementations of XPointer. One precondition of any license granted to a party shall be the party's agreement to grant royalty-free licenses to Sun and other companies to make, use, sell, offer for sale, or import implementations of XPointer under the party's essential patent claims. Sun expressly reserves all other rights it may have..." (see the remainder). The text of the earlier patent statement is available in the W3C mailing list archives for 'www-xml-linking-comments'. [source]

• [April 19, 2001] "Transitive closure for XPath." By Christian Nentwich (Department of Computer Science, University College London). "During the last couple of months, while working on xlinkit and my thesis, I have had to deal with several cases where I had to compute the transitive closure of elements in XML files inside an xpath expression. Unfortunately, XPath has no proper transitive closure operator. Let me give you an example. The XMI standard specifies a DTD for encoding UML models. My thesis is to do with consistency checking, and one of the rules in the UML is that no class can be a superclass and a subclass of another at the same time. In order to specify this rule, I have to compute the set of parent classes and the set of descendent classes for each class - transitively. It helps to have a look at some XMI fragments to understand the complexity of the problem, I've only left in the relevant bits... I propose that a new function be added to xpath, closure(node-set,node-set). This function will first evaluate its first parameter to form a base set. It will then repeatedly evaluate the second parameter, which has to be a relative expression, over the base set, to form a new base set..." [XML-DEV note: "Something I really lose sleep over is the lack of a transitive closure function in XPath. I use XPath standalone, outside XSLT and I need such an operator (to compute the set of all parent classes of a class in XMI, for example). Would you please comment on [this] little proposal I have written? It includes an implementation of the operator for Xalan as a freebie. Just imagine what this operator could do for your family tree XSLT stylesheet. Am I the only one who finds this (extremely) useful? Please comment."]

• [April 16, 2001] "The Design of the DocBook XSL Stylesheets." By Norman Walsh (XML Standards Engineer Sun Microsystems, Technology Development Center). Paper presented at XSLT-UK 01 (08 Apr - 09 Apr 2001, Keble College, Oxford, England). 08-April-2001. Version 1.0. "Building stylesheets for a large, rich XML vocabulary is a challenging exercise. This paper explores some of the design issues confronted by the author in designing XSL stylesheets for DocBook, an XML DTD maintained by the DocBook Technical Committee of OASIS. It is particularly well suited to books and papers about computer hardware and software (though it is by no means limited to these applications). DocBook consists of nearly 400 tags. The HTML and Formatting Object stylesheets each consist of roughly 1000 templates spread over about 30 files. The design for the DocBook XSL Stylesheets attempts to meet the following goals: (1) Full support for all of DocBook. (2) Full support for both HTML and XSL Formatting Object presentations. (3) Utility for a wide range of users, with varying levels of technical skill. (4) Support across diverse hardware and software platforms. (5) Provide a framework on top of which additional stylesheets can be written for schemas derived from DocBook. (6) Support for internationalization. (7) Support for a wide range of projects (books, articles, online- and print-centric presentations, etc.) Although not all of these goals have been completely achieved, progress has been made on all of them. Five techniques stand out as important factors in achieving these goals: modularity, parameterization, self-customizing stylesheets, 'literate' programming, and extensions. The rest of this paper will discuss these techniques in detail... [Conclusion:] XSL Transformations and Formatting Objects are a rich platform on which to build stylesheets for large, sophisticated XML vocabularies. Designing stylesheets that will be adaptable and maintainable is an interesting software engineering challenge. In this paper we've examined five factors that contribute to the successful design of XSL stylesheets: modularity, parameterization, stylesheet generation, documentation, and XSLT extensions." References: (1) "DocBook XML DTD"; (2) "SGML/XML and Literate Programming."

• [April 06, 2001] "Transforming XML: Namespaces and XSLT Stylesheets." By Bob DuCharme. From XML.com. April 04, 2001. ['A guide to using XSLT to create documents that use XML Namespaces.'] "In XML a namespace is a collection of names used for elements and attributes. A URI (usually, a URL) is used to identify a particular collection of names. Instead of including the URI with every element to show which namespace it came from, it's more convenient to name a short abbreviation when a namespace is declared and to then use that abbreviation to identify an element or attribute's namespace. Many simple XML applications never need to declare and use namespaces. If they don't, the XML processor treats all elements and attributes as being in the default namespace. This may be the case with some of your source documents, but it's certainly not the case with your XSLT stylesheets: the declaring and referencing of the XSLT namespace is how we tell an XSLT processor which elements and attributes in a stylesheet to treat as XSLT instructions... In this column, we've seen how to control the namespaces that are declared and referenced in your result document. Next month, we'll see how your XSLT stylesheet can check which namespaces are used in your source document and perform tasks based on which namespace each element belongs to."

• [March 29, 2001] "XSLT Processor Benchmarks." By Eugene Kuznetsov and Cyrus Dolph. From XML.com. March 28, 2001. [The latest benchmark figures for XSLT processors show Microsoft's processor riding high, with strong performance from open source processors... XML.com is pleased to bring you the results of performance testing on XSLT processors. XSLT is now a vital part of many XML systems in production, and choosing the right processor can have a big impact. Microsoft's XSLT processor, shipped with their MSXML 3 library, comes top of the pile by a significiant margin. After Microsoft, there's a strong showing from the Java processors, with James Clark's XT--considered by many an "old faithful" among XSLT engines--coming ahead of the rest. Still, speed isn't everything, and most XSLT processors are incomplete with their implementation of the XSLT 1.0 Recommendation. On this score, Michael Kay's Saxon processor offers good spec implementation as well as respectable performance.'] "XSLTMark is a benchmark for the comprehensive measurement of XSLT processor performance. It consists of forty test cases designed to assess important functional areas of an XSLT processor. The latest release, version 2.0, has been used to assess ten different processors. This article describes the benchmark methodology and provides a brief overview of the results... The performance of XML processing in general is of considerable concern to both customers and engineers alike. With more and more XML-encoded data being transmitted and processed, the ability to both predict and improve XML performance is critical to delivering scalable and reliable solutions. While XSLT is a big part of delivering on the overall value proposition of XML (by allowing XML-XML data interchange and XML-HTML content presentation), it also presents the greatest performance challenge. Early anecdotal evidence showed wide disparities in real-life results, and no comprehensive benchmark tools were available to obtain more systematic assessments and comparisons... Of the processors included in this release of the benchmark, MSXML, Microsoft's C/C++ implementation, is the fastest overall. The three leading Java processors, XT, Oracle and Saxon, have surpassed the other C/C++ implementations to take 2nd through 4th place respectively. This suggests that high-level optimizations are more important than the implementation language in determining overall performance. The C/C++ processors tend to show more variation in their performance from test case to test case, scoring some very high marks alongside some disappointing performance. XSLTC aside, the C/C++ processors won first place in 33 of the 40 test cases, in some cases scoring two to three times as well as their Java competitors (attsets, dbonerow). This suggests that there is a lot of potential to be gained from using C/C++, but that consistent results might be harder to obtain..." Tool: XSLTMark; see also Kevin Jones' XSLBench test suite.

• [March 29, 2001] "XSLT Benchmark Results." By Eugene Kuznetsov and Cyrus Dolph. From XML.com. March 28, 2001. ['The full results from the DataPower XSLT processor benchmarks.'] XSLTMark gauges the capabilities of XSLT processing engines by testing them on a common platform with a variety of stylesheets and inputs that sample the gamut of possible applications. See the XSLTMark overview for more information about the benchmark itself and how to download it. These results were obtained by DataPower on a Pentium III/500 machine running Linux. We encourage XSLT engine authors and users to submit benchmark results on their platforms, as well as drivers for new processors. Test results for the following XSLT processors are available: Overall Chart; 4Suite 0.10.2 (Fourthought); Gnome XSLT 0.5.0 (Gnome Project); MSXML 3.0 (Microsoft); Oracle XSLT 2.0 (Oracle); Sablotron 0.51 (Ginger Alliance); Saxon 6.2.1 (Michael Kay); TransforMiiX 0.8 (Mozilla Project); Xalan-C++ 1.1 (Apache Project); Xalan-Java 2.0.0 (Apache Project); XSLTC alpha 4(Sun); XT 19991105 (James Clark); Key." See previous article.

• [March 15, 2001] "EXSLT 1.0 Drafts." From Jeni Tennison. Posting to XSL-List. (1) Common - EXTENSIONS TO XSLT 1.0 (EXSLT 1.0) - COMMON. "This document describes the common set of EXSLT 1.0. EXSLT 1.0 is a set of extension elements and functions that XSLT authors may find helpful when creating stylesheets. The common set of EXSLT 1.0 are those extension elements and functions that provide a base level of common functionality that the rest of EXSLT can build on. XSLT processors are free to support any number of the extension elements and functions described in this document. However, an XSLT processor must not claim to support EXSLT 1.0 - Common unless all the extensions described within this document are implemented by the processor. An implementation of an extension element or function in an EXSLT namespace must conform to the behaviour described in this document." (2) Functions - EXTENSIONS TO XSLT 1.0 (EXSLT 1.0) - FUNCTIONS. "This document describes EXSLT 1.0 - Functions. EXSLT 1.0 is a set of extension elements and functions that XSLT authors may find helpful when creating stylesheets. EXSLT 1.0 - Functions are those extension elements and functions that allow users to define their own functions for use in expressions and patterns in XSLT." (3) Sets - EXTENSIONS TO XSLT 1.0 (EXSLT 1.0) - SETS. "This document describes EXSLT 1.0 - Sets. EXSLT 1.0 is a set of extension elements and functions that XSLT authors may find helpful when creating stylesheets. EXSLT 1.0 - Sets covers those extension elements and functions that provide facilities to do with set manipulation." (4) Math - EXTENSIONS TO XSLT 1.0 (EXSLT 1.0) - MATH. "This document describes EXSLT 1.0 - Math. EXSLT 1.0 is a set of extension elements and functions that XSLT authors may find helpful when creating stylesheets. EXSLT 1.0 - Math covers those extension elements and functions that provide facilities to do with maths."

• [March 15, 2001] XML-Deviant: Extensions to XSLT." By Leigh Dodds and Jeni Tennison. From XML.com. March 14, 2001. ['Members of the XSL mailing list have started a commnunity-based project to standardize extensions for XSLT.'] "The community has discussed alternatives to the contentious <xsl:script> element... the major concerns over xsl:script were that it would encourage scripting code, authored in Java, Javascript, VBScript and other languages, to be embedded inside XSLT stylesheets hampering usability and (potentially) interoperability. The discussion lead to suggestions that XSLT extension functions might usefully be implemented in XSLT itself, rather than, or perhaps in parallel to, implementations in other languages. A number of ways of achieving this functionality were suggested, resulting in Jeni Tennison gathering together the alternatives to further focus the debate and achieve progress: 'There seems to be a reasonable amount of support for user-defined functions written in XSLT, whether to sweeten the syntax of xsl:call-template or to allow XPaths previously only dreamed about. If we're going to move ahead with this, we need to agree on a syntax for (1) declaring the functions and (2) calling the functions. In this email, I'm going to lay out the major designs that have been suggested so far so that we can discuss them and hopefully come up with some kind of resolution that's acceptable to everyone...' What are EXSLT's advantages given that XSLT already provides an user extension mechanism? First, it ensures that the extension functions are well defined in a community-drafted specification, avoiding the need for XSLT developers to rely on proprietary definitions of similar functions provided by their stylesheet engine. Also, while the implementation language for a function may vary, developers can ensure that functions will remain consistent across processors. Second, by providing the means to define their own functions in XSLT, stylesheet authors can create truly portable stylesheets that rely only on a conformant XSLT 1.0 processor that implements the elements defined in EXSLT - Functions... A deciding factor in the success of EXSLT will be whether it's supported by XSLT engines. The prospects are promising, particularly as 4XSLT has already adopted the proposed functions. If the developers of Xalan and other stylesheet engines adopt it, then the future looks decidedly rosy for XSLT developers."

• [March 15, 2001] Transforming XML: Entities and XSLT." By Bob DuCharme. From XML.com. March 14, 2001. ['Using XML entities can be tricky -- this article covers their usage with XSLT in both input and output documents.'] "In XML, entities are named units of storage. Their names are assigned and associated with storage units in a DTD's entity declarations. These units may be internal entities, whose contents are specified as a string in the entity declaration itself, or they may be external entities, whose contents are outside of the entity declaration. Typically, this means that the external entity is a file outside of the DTD file which contains the entity declaration, but we don't say 'file' in the general case because XML and XSLT work on operating systems that don't use the concept of files. A DTD might declare an internal entity to act like a constant in a programming language. For example, if a document has many copyright notices that refer to the current year, declaring an entity cpdate to store the string '2001' and then putting the entity reference '&cpdate;' throughout the document means that updating the year value to '2002' for the whole document will only mean changing the declaration. Internal entities are especially popular to represent characters not available on computer keyboards... Because an XSLT stylesheet is an XML document, you can store and reference pieces of it using the same technique, but you'll find that the xsl:include and xsl:import instructions give you more control over how your pieces fit together. . . All these categories of entities are known as parsed entities because an XML parser reads them in, replaces each entity reference with the entity's contents, and parses them as part of the document. XML documents use unparsed entities, which aren't used with entity references but as the value of specially declared attributes, to incorporate non-XML entities. When you apply an XSLT stylesheet to a document, if entities are declared and referenced in that document, your XSLT processor won't even know about them..."

• [March 03, 2001] "Petition to withdraw xsl:script from XSLT 1.1." By Clark C. Evans, Peter Flynn, Alexey Gokhberg, et al.. See the posting of 2001-03-01. "XSLT provides an extension mechanism whereby additional functionality can be identified with a URI reference and implemented in a manner defined by a particular XSLT processor. This mechanism provides an opaque layer between the extension function's usage and its implementation -- allowing for many implementations of an extension function regardless of language or platform. This extension facility provides a rich playground where new features can be prototyped and even put into production. However, to balance this much-needed flexibility, the syntax makes it clear that such added functionality is, in fact, an 'extension' and therefore may not be portable across XSLT implementations. Success of this extension mechanism has brought about request for change by several parties. One change is the official Java and Javascript extension function binding. Although this petition does not specifically challenge this addition, some question the wisdom of this decision. An official binding could encourage wholesale importation of constructs from Java and Javascript into XSLT without thought as to how those constructs would or should be supported in XSLT proper. A second change, the addition of xsl:script, is what we challenge with this petition. As users and implementers of XSLT, we request that the W3C withdraw section 14.4, Defining Extension Functions from the current XSLT 1.1 working draft for the following reasons [...]" Note: this petition created some controversy on the XSL-List.

• [March 02, 2001] "EXSLT 1.0 - Common, Sets and Math." Posting from Jeni Tennison to the XSL-List. March 02, 2001. Thanks to those of you that commented on the last EXSLT draft. I've put up a new draft for user-defined functions and a couple of handy extension functions at: http://www.jenitennison.com/xslt/exslt/common/. There's a list of changes to the last draft there, but also of interest is that I've created a couple more documents at: http://www.jenitennison.com/xslt/exslt/sets/ and http://www.jenitennison.com/xslt/exslt/math/ that hold some extension functions. These are intended to be a starting point for a number of groups of standard (built-in) functions. The most important issues for developing these functions are (a) whether there are other sets of functions that we should define and (b) what functions we should have in them. These documents are just a starting point - please post any comments and suggestions here..."

• [March 02, 2001] "What Kind of Language is XSLT? An Analysis and Overview." By Michael H. Kay (Software AG). From IBM developerWorks. February, 2001. ['What kind of a language is XSLT, what is it for, and why was it designed the way it is? These questions get many different answers, and beginners are often confused because the language is so different from anything they are used to. This article tries to put XSLT in context. Without trying to teach you to write XSLT style sheets, it explains where the language comes from, what it's good at, and why you should use it.'] I originally wrote this article to provide the necessary background for a technical article about Saxon, intended to provide insights into the implementation techniques used in a typical XSLT processor, and therefore to help users maximize the performance of their style sheets. But the editorial team at developerWorks persuaded me that this introduction would be interesting a much wider audience, and that it was worth publishing separately as a free-standing description of the XSLT language. What is XSLT? The XSLT language was defined by the World Wide Web Consortium (W3C), and version 1.0 of the language was published as a Recommendation on November 16, 1999. I have provided a comprehensive specification and user guide for the language in my book XSLT Programmers' Reference and I don't intend to cover the same ground in this paper. Rather, the aim is simply to give an understanding of where XSLT fits in to the grand scheme of things. The role of XSLT: XSLT has its origins in the aspiration to separate information content from presentation on the Web. HTML, as originally defined, achieved a degree of device independence by defining presentation in terms of abstractions such as paragraphs, emphasis, and numbered lists. As the Web became more commercial, publishers wanted the same control over quality of output that they had with the printed medium. This gradually led to an increasing use of concrete presentation controls such as explicit fonts and absolute positioning of material on the page. The unfortunate but entirely predictable side effect was that it became increasingly difficult to deliver the same content to alternative devices such as digital TV sets and WAP phones (repurposing in the jargon of the publishing trade)... As a programming language, XSLT has many features -- from its use of XML syntax to its basis in functional programming theory -- that are unfamiliar to the average Web programmer. That means there is a steep learning curve and often a lot of frustration. The same was true of SQL in the early days, and all that this really proves is that XSLT is radically different from most things that have gone before. But don't give up: It's an immensely powerful technology, and well worth the effort of learning."

• [March 02, 2001] "Saxon: The Anatomy of an XSLT Processor. What is current state of the art in XSLT optimization?" By Michael H. Kay (Software AG). From IBM developerWorks. February, 2001. [' This article describes how an XSLT processor, in this case the author's open-source Saxon, actually works. Although several open-source XSLT implementations exist, no one, as far as we know, has published a description of how they work. This article is intended to fill that gap. It describes the internal workings of Saxon, and shows how this processor addresses XSLT optimization. It also shows how much more work remains to be done. This article assumes that you already know what XSLT is and how it works.'] "I hope this article serves a number of purposes. First, I hope it will give style sheet authors a feel for what kind of optimizations they can expect an XSLT processor to take care of, and by implication, some of the constructs that are not currently being optimized. Of course, the details of such optimizations vary from one processor to another and from one release to another, but I'm hoping that reading this account will give you a much better feel for the work that's going on behind the scenes. Second, it describes what I believe is the current state of the art in XSLT technology (I don't think Saxon is fundamentally more or less advanced than other XSLT processors in this respect), and describes areas where I think there is scope for further development of techniques. I hope this description might stimulate further work in this area by researchers with experience in compiler and database optimization. Finally (last and also least), this article is intended to be a starting point for anyone who wants to study the Saxon source code. It isn't written as a tour of the code, and it doesn't assume that you want to go into that level of depth. But if you are interested in getting a higher-level overview than you can get by diving into the JavaDoc specs or the source code itself, you'll probably find this useful... I try in this article to give an overview of the internals of the Saxon XSLT processor, and in particular of some of the techniques it uses to improve the speed of transformation. In the 18 months or so since I released the first early versions of Saxon, performance has improved by a factor of 20 (or more, in the case of runs that were thrashing for lack of memory). Perhaps the biggest research challenge is to write an XSLT processor that can operate without building the source tree in memory. Many people would welcome such a development, but it certainly isn't an easy thing to do."

• [February 27, 2001] "FXPath - Functional XPath." By David Rosenborg (Pantor Engineering AB). February 27, 2001. ['A comment on the document "User-Defined Extension Functions in XSLT" (called EXSL here), written by Jeni Tennison.] "The purpose of this document is to outline an alternative approach to writing extension functions in XSLT.The EXSL document and this document result from a recent discussion on the XSL mailing list (xsl-list@lists.mulberrytech.com). The EXSL document is in large an excellent compilation and presentation of the ideas and issues discussed on the XSL list. However, the EXSL document presents one of two rather different approaches on how to implement the extension functions. This document tries to present the other. The EXSL approach is to retrofit some XSLT instructions so that they can deal with all types in XPath, notably node sets. This document wants to show that there is a more natural way to accomplish the same result: write extension functions in XPath to deal with XPath types. Since XPath 1.0 lacks some vital constructs to do this, this document presents a superset, called Functional XPath (FXPath), that makes this possible in a convenient way. This document has a much narrower scope than the EXSL specification. It is concentrated around how to actually define the extension functions. The issues on calling functions, defining sets of common extension functions etc are well covered in EXSL and are not handled here. However, the set of example functions are reimplemented here, in FXPath, to enable a side by side comparison..."

• [February 27, 2001] "User-Defined Extension Functions in XSLT." By Jeni Tennison. February, 2001. [A draft document that summarises recent public discussions on user-defined extension functions written in XSLT; informed and inspired by discussions on XSL-List with David Carlisle, Joe English, Clark C. Evans, Dave Gomboc, Yevgeniy (Eugene) Kaganovich, Mike Kay, Steve Muench, Miloslav Nic, Francis Norton, Dimitre Novatchev, Uche Ogbuji, and David Rosenborg.] "This document describes a method for defining user extension functions using XSLT in XSLT 1.0. XPath contains a number of functions that allow you to perform manipulation of strings, numbers, node sets and so on. While these cover basic functionality, there are often situations where stylesheet authors either need to or want to do more within an XPath. Most XSLT applications offer a range of extension functions. However, using only implementation's extension functions limits the stylesheet author to those thought of and implemented by a particular vendor. It also means that the stylesheet itself is limited to that vendor. Allowing users to define their own extension functions enables them to create the functions that they need for their particular application and enhances the portability of their stylesheets. Stylesheet authors need to have a ways of defining their own functions. These definitions may be in any programming language, but it is likely that different XSLT processors will support different languages. The one language that all XSLT processors support is XSLT. It therefore makes sense to allow stylesheet authors to define extension functions using XSLT - the implementation may not be as efficient as it would be in, say, Java, but at least it can be supported across platforms and implementations, and limits the number of langauges that stylesheet authors have to learn... This document is a first draft for review by the implementers of XSLT processors and the XSLT stylesheet authors. It is based on discussions on XSL-List. Comments on this document should be sent to XSL-List..." [cache]

• [February 20, 2001] "[XSLT Tutorial. Part 1]." By Henning Behme. From iX/Raven - iX - Magazin für professionelle Informationstechnik. February 19, 2001. "In order to present XML documents or data to the user in an attractive way in browser, mobile phone or PDF format, the original data must first be converted to the necessary formats. This is the purpose of XSLT as part of the style component of XML... The tutorial begins with the basics and finishes by trying out AxKit (v 1.2) for serving XML sources dynamically." The three-part tutorial series is also available in German. See details.

• [February 20, 2001] "Dynamically Generated XSL Revisited. [XML@Large.]" By Michael Floyd. In WebTechniques Volume 6, Issue 03 (March 2001), pages 66-69. ['You could write over 100 style sheets, or you could let some transformations do all the work. Michael Floyd gives you the short story.'] "In the January installment of this column, I demonstrated how to dynamically generate XSL style-sheet transformations, which can then be applied to XML documents. In that column, I assumed that the developer has intrinsic knowledge of the structure and organization, or "schema," of the data being transformed. That knowledge is important because style-sheet transformations often use simple step patterns (or even full-blown XPath expressions) to locate a given element or attribute in the document tree, then use <xsl:value-of> to retrieve the item's content. So, XSL style sheets are highly reliant on a document's structure. By moving from statically created style sheets to dynamically generated transformations, you shift responsibility from the style-sheet author to the DOM developer. However, if you can generalize the process, you can realize significant benefits from generating your XSL dynamically. The key to generalizing this process lies in the schema. If you have a formal schema, such as a DTD or XML Schema document, you should be able to discover enough about the organization and structure to generate a reasonable XSL style-sheet document. This month, I'll examine that process and discuss how far you can take it. I wrote this article with the assumption that you, the developer, are familiar with XML Data Reduced (XDR) schemas, the XSL Transformation language (XSLT), and the Document Object Model (DOM)... Style sheets are used to associate meaning with markup elements, preventing us from completely generalizing style-sheet transformations. You can't render a <bold> element unless you know how to generate the appropriate transformation. There are a few ways to solve this problem. One is to let the user associate meaning interactively. You might create a tool that scans the schema, presents a list of all elements (and appropriate attributes), and lets an end user assign a property or behavior. An even simpler method is to create a mapping in your code between markup elements and their transformations. Either way, by moving from statically created style sheets to dynamically generated transformations you can solve the problem of propagating style sheets, and reduce maintenance of them, while generalizing the overall process."

• [February 16, 2001] "Rescuing XSLT from Niche Status. A Gentle Introduction to XSLT through HTML Templates." By David Jacobs (Mitre). [February, 2001.] Via Roger L. Costello. "XSLT is one of the most exciting technologies to come out of the XML family. Unfortunately, its incredible power and associated complexity can be overwhelming to new users preventing many from experimenting with it or causing them to quickly give up in disgust. In fact, unless the method of teaching and the common style of use for XSLT is radically changed to make it more accessible, XSLT will be relegated to niche status... we can see why embedded web scripting languages like Active Server Pages (ASPs), Cold Fusion, PHP and Java Server Pages (JSPs) are so popular. They all leverage a user's knowledge of HTML. They also allow the minimum amount of scripting to be added to accomplish the dynamic feature a developer is looking for. This has allowed numerous web developers to start off with very small projects and then through continuous enhancement and learning, find themselves using the full power of a complex programming language. Furthermore, because of the very incremental nature of that learning the developer was never scared off... So how do we solve this problem and help deliver XSLT's promise to the masses'? For XSLT to be successful it must be presented and used in a way that adopts those attributes discussed earlier (reuse of knowledge, fast start, and gradualism). This tutorial will attempt to ease XSLT's introduction by focusing on these attributes. First, it is only going to focus on the generation of HTML documents and users who are familiar with HTML. If your goal is to immediately start transforming one XML document into another XML document this tutorial is not for you. The second is to reframe the problem so the XSLT solutions programmers write are more naturally extensible and intuitive. Instead of trying to translate an XML source document into an HTML presentation document, the programmer should see the XML document as a complex data structure with XSLT providing powerful tools for extracting that information into their HTML documents. This allows us to leverage the experience most people have with using an HTML templating language (e.g. ASP, PHP, JSP, Cold Fusion, Web Macro, etc). These templating languages are all based on the basic premise that HTML comes first and all enhancements are then embedded in special tags. Thus, the problem is reframed as: how do I create XSL-enhanced HTML documents? With some caveats, this tutorial will show how XSLT can be used in this same way. The benefit of this approach is it allows the quick use of many of XSLT's powerful functions while letting you learn its more esoteric capabilities as the need arises. In addition the resulting XSLT files are more intuitive and maintainable..."

• [February 15, 2001] "XML-Deviant: XSLT Extensions Revisited." By Leigh Dodds. From XML.com. February 14, 2001. ['The first Working Draft of XSLT 1.1, though attempting to address the portability of stylesheets that use extension functions, has failed to please everyone in the XSLT developer community.'] "Early last year the XML Deviant reported on concerns expressed among the XSLT development community about portability of XSLT stylesheets. And despite publication of the XSLT 1.1 Working Draft which attempts to address these issues, some developers are still far from happy... In March 2000 the Deviant summarized a debate that ranged over several mailing lists. Its subject was concerns about lack of portability of stylesheets among the major XSLT engines. While the XSLT specification defined a language-neutral extension mechanism for extension functions, implementors were tied to the proprietary APIs provided by a particular XSLT engine. This meant that functions, and hence stylesheets, were not portable. (See "Unifying XSLT Extensions" for additional background.) At the time the consensus was that a standardized language binding was required, along with implementations of common extension functions. Shortly thereafter the XSL Working Group announced that it was aware of these concerns and was planning to address them in a revision of the XSLT specification..."

• [February 09, 2001] "Transforming XML: Setting and Using Variables and Parameters." By Bob DuCharme. From XML.com. February 07, 2001. ['This article shows how variables and parameters can be used in XSLT stylesheets to substitute values into templates.'] "A variable in XSLT has more in common with a variable in algebra than with a variable in a typical programming language. It's a name that represents a value and, within a particular application of a template, it will never represent any other value -- it can't be reset using anything described in the XSLT Recommendation. (Some XSLT processors offer a special extension function to allow the resetting of variables.) XSLT variables actually have a lot more in common with constants in many programming languages and are used for a similar purpose. If you use the same value multiple times in your stylesheet, and there's a possibility that you'll have to change them all to a different value, it's better to assign that value to a variable and use references to the variable instead. Then, if you need to change the value when re-using the stylesheet, you only change the value assigned in the creation of that variable..." DuCharme has presented several other articles in this column 'Transforming XML'.

• [February 05, 2001] "Pushing the Boundaries of the Web." By Kurt Cagle. In XML Magazine Volume 2, Number 1 (February/March 2001). ['Take advantage of the powerful Web design potential offered by extending your XHTML with XSLT. Kurt discusses the advantages of using XSLT libraries and XSLT-based transformations in your Web page code.'] "Using XSLT to extend XHTML means that you can view complex interfaces in terms of dynamic components and change the look, feel, and data content of your pages. Web page design is hard. There, I've said it. Many developers scoffed at the hordes of HTML "programmers" who began working with HTML as far back as 1993 -- these baby programmers weren't working with real languages like C++. This same crew thought that Visual Basic programmers were baby programmers and denigrated the Java programmers who emerged in 1995-1996 as 'not real developers,' either. Perhaps a little elitism was at work. The stigma attached to HTML coders has remained, although these folks are attempting to do something impressive. They are attempting to write code that can produce similar (and similarly functioning) Web pages and work on six or seven browsers that span four major operating systems -- and produce a prodigious amount of content. Any good Web publisher probably has a set of extensive ASP, JSP, or Perl scripts that handle the generation of much of the continuity material -- navigation menus, top stories, boilerplate code, and so forth. The irony here is that most of the code that is produced to do this is written by programmers who are used to writing code in Visual Basic or Java. However, the cost for getting these programmers to write these routines is significant. Neither VB nor Java is especially geared toward the manipulation of strings, so a lot of effort is expended in writing ASP code, in particular where the code processing is intermingled with HTML (or that encodes the HTML within quoted strings, which is even less legible). This significantly limits the ability of programmers to create generalized routines. XSLT was supposed to change this scenario, but in many cases, XSLT code is just as thoroughly intertwined with the output code as was ASP. The fact that the embedded and embedding content are in XML gives you some advantages, but ultimately it would be nice to be able to have a simple HTML-like document where you could just create your own general tags,

• [January 25, 2001] Tutorials: Using XSL Formatting Objects, Part 2." By J. David Eisenberg. From XML.com. January 24, 2001. ['The second part of our XSL Formatting Objects tutorial explains how to use lists and tables in documents.'] " This article is the second part of our series on using XSL Formatting Objects. You should read the first article before proceeding with this one. Having tackled the cover and contents page in the previous article, we're now ready to put the main content into the Spanish handbook..."

• [January 18, 2001] "Tutorial: Using XSL Formatting Objects." By J. David Eisenberg. From XML.com. January 17, 2001. ['The W3C's XSL Formatting Objects technology provides an XML language for specifying the layout of documents. In the first article of our XSL FO tutorial series we show you how to set up your pages.'] "The World Wide Web Consortium's specification for Extensible Stylesheet Language (XSL) comes in two parts: (1) XSLT, a language for transforming XML documents, and (2) XSL Formatting Objects (XSL FO), an XML vocabulary for specifying formatting semantics... . XSL Formatting Objects is itself an XML-based markup language that lets you specify in great detail the pagination, layout, and styling information that will be applied to your content. The XSL FO markup is quite complex. It is also verbose; virtually the only practical way to produce an XSL FO file is to use XSLT to produce a source document. Finally, once you have this XSL FO file, you need some way to render it to an output medium. There are few tools available to do this final step. For these reasons, XML FO has not caught on as quickly as XSLT. Rather than explain XSL FO in its entirety, this article will give you enough information to use the major features of XSL FO. Our case study will be a short review handbook of Spanish that will be printed as an insert for a Spanish language learning CD-ROM. We'll use the Apache Software Foundation's FOP tool to convert the FO file to a PDF file... In the next article, we'll show you how to use XSLT to make it much easier to create the FO elements. You'll also learn how to put lists and tables into your documents."

• [January 09, 2001] "Improve your XSLT coding five ways. Tips to make you a better XSLT programmer." By Benoît Marchal (Software Engineer, Pineapplesoft). IBM DeveloperWorks XML Library. January 2001. ['Whether you're a beginner with XSLT or a seasoned programmer, you'll surely find that these five tips from Benont Marchal will improve your coding and give you new ideas. The handful of tips cover using CSS with XSL style sheets (including HTML entities), incorporating client-side JavaScript, working with multiple input documents, and using XSLT to generate style sheets automatically. The article includes sample code to adapt and reuse.'] "The combination of XML and XSLT is growing in popularity with webmasters of medium-sized and large Web sites. Prior to XSLT, changing the presentation of a Web site was a major undertaking: one had to revisit and to change every page on the site. XSLT automates the process, leading to significant time savings... The moral of the story: If you are after maximum automation for a large Web site, it is not enough to generate HTML documents automatically from XML documents, you ought to automatically generate XSLT style sheets as well." See also the PDF version. [Benont Marchal is a software engineer and writer based in Namur, Belgium, who has worked extensively in Java and XML. He's the author of two books on XML: XML by Example and Applied XML Solutions.]

• [January 05, 2001] "XSLT's Template Dispatch." By Clark C. Evans. 2001-01-05. Document authored December 1, 2000. "XSLT is a language for transforming XML texts. The language includes familiar constructs such as for-each iteration, conditional statements, and callable functions. XSLT also includes an additional control structure, the template dispatch, which occurs through the interaction of apply-template/select and template/match. This paper presents two templates, one of which uses the template dispatch, and a second, functionally equivalent to the first, which is constructed without the help of this control structure. This paper then concludes with a comparison which may help to elucidate the power and elegance of XSLT's template dispatch..."

• [November 22, 2000] "A formal model for an expressive fragment of XSLT." By Geert Jan Bex, Sebastian Maneth, and Frank Neven. Pages 1137-1151 in [J. Lloyd et. al., eds.], Proceedings of Computational Logic -- CL 2000, First International Conference, LNCS 1861, Springer-Verlag, 2000. 16 pages, with 26 references. "The aim of this paper is two-fold. First, we want to show that the recent extension of XSL with variables and passing of data values between template rules has increased its expressiveness beyond that of most other current XML query languages. Second, in an attempt to increase the understanding of this already wide-spread but not so transparent language, we provide an essential and powerful fragment with a formal syntax and a precise semantics... XSL is a current W3C proposal for an XML extensible stylesheet language. Its original primary role was to allow users to write transformations of XML to HTML, thus describing the presentation of XML documents. Nowadays, many people use XSL as their basic tool for XML to XML transformations which renders XSL into an XML query language. It has been noted by the database community, though, that the transformations XSL can express are rather limited. For instance, XSL does not have joins or skolem-functions (and, hence cannot do sophisticated grouping of output data). In other words, XSL lacks the most basic property any query language should have: it is not relationally complete. However, as the language is still under development, some features have changed over time. Recently various extensions were added to the language. The most apparent ones being the addition of variables and parameter passing between template rules. We show that these additions, together with the use of modes (which are actually states as used in finite state machines and which were already defined in earlier versions of XSL) render XSL into a powerful query language. Indeed, XSL not only becomes relationally complete, but it can do explicit grouping (with or without skolem functions), it can simulate regular path expressions, and it can simulate all other current XML query languages. . . Actually together with the addition of the new features, XSL was split into two parts: XSL Transformations (XSLT) and XPath. The latter contains the description of XSL's associated pattern language, while the former defines the real transformation language. To emphasize that we are focusing on the transformation part, with the new features, we refer to XSL by XSLT in the rest of this paper. The main source for the definition of XSLT is its specification which is a bit difficult to read, especially when one only wants an impression of how the language works or what it is capable of. To remedy this, we define an abstract formal model of XSLT incorporating most of its features, but all of those which are necessary to simulate, say, XML-QL. The purpose of this model is two-fold: (i) the clean and formal semantics provides the necessary mathematical model for studying properties of XSLT; (ii) our formal model abstracts away from the actual syntax of XSLT and emphasizes on its features in such a way that the interested reader can get a feeling of the language and what it is capable of. Next, we use this model to gain some insight in XSLT. First, we obtain that XSLT can compute all unary monadic second-order (MSO) structural properties. In brief, MSO is first-order logic (FO) extended with set quantification and is an expressive and versatile logic: on trees, for instance, it captures many robust formalisms, like regular tree languages], query automata, finite- valued attribute grammars .... Moreover, MSO can take the inherent order of children of vertices into account, a desirable property for XML pattern languages. By structural patterns we mean MSO without joins, that is, we cannot check whether the values of two attributes are the same. In fact, Neven and Schwentick showed that, already w.r.t. structural patterns, MSO is more expressive than FO extended with various kinds of regular path expressions. Thus, as most current XML query languages are based on FO extended with regular path expressions, this already indicates that XSLT cannot be simulated by, say, XML-QL. Next, we show that XSLT can simulate most existing XML query languages. To study decidability of type checking, Milo, Suciu, and Vianu defined the k- pebble tree-transducer as a formalism capturing the expressiveness of all existing XML query languages, including XML-QL, XQL, Lorel, StruQL, UnQL and the previous version of XSL. Their model does not take value equation into account (needed for joins, for instance) but can easily be modified to do so. We obtain that XSLT can simulate this model, thereby establishing XSLT to be more expressive than all of the above. For more concrete simulations, we refer the interested reader to [3], were we show how the XML-QL queries in can be expressed in actual XSLT. We want to emphasize that we do not provide a model for all of XSLT. For instance, we excluded for-loops and variables can only be instantiated by data values (not by result tree fragments). The idea is that we want to use variables as a look-ahead or to fetch data values occurring 'far' from the current node. The resulting language is, hence, not Turing complete and, hopefully, more efficient to evaluate. The study of the properties of our formal model, however, is beyond the scope of the present paper. The most important fact is that the defined language is more expressive than, say, XML-QL, as opposed to the previous version of XSL..." [cache]

• [September 07, 2000] "Transforming XML with XSLT." Chapter 7, "Beta" from Building Oracle XML Applications, by Steve Muench. We've used XSLT stylesheets in previous chapters to transform database-driven XML into HTML pages, XML datagrams of a particular vocabulary, SQL scripts, emails, and so on. If you're a developer trying to harness your database information to maximum advantage on the Web, you'll find that XSLT is the Swiss Army knife you want permanently attached to your belt. In a world where the exchange of structured information is core to your success, and where the ability to rapidly evolve and repurpose information is paramount, Oracle XML developers who fully understand how to exploit XSLT are way ahead of the pack. XSLT 1.0 is the W3C standard language for describing transformations between XML documents. It is closely aligned with the companion XPath 1.0 standard and works in concert with it. As we'll see in this chapter, XPath lets you say what to transform, and XSLT provides the complementary language describing how to carry out the transformation. An XSLT stylesheet describes a set of rules for transforming a source XML document into a result XML document. An XSLT processor is the software that carries out the transformation based on these rules. In the simple examples in previous chapters, we have seen three primary ways to use the Oracle XSLT processor. We've used the oraxsl command-line utility, the XSLT processor's programmatic API, and the <?xml-stylesheet?> instruction to associate a stylesheet with an XSQL page. In this chapter, we begin exploring the full power of the XSLT language to understand how best to use it in our applications..." ['Steve said on XML-DEV: "O'Reilly published a beta chapter today on their website of my forthcoming book Building Oracle XML Applications. It's the chapter that explains the fundamentals of XSLT through a number of examples. I highly recommend the PDF version (over the HTML version) for printing out and reading. The book focuses on being an example-rich tutorial for Java and PL/SQL developers to learn the basics of XML, XPath, and XSLT, and how to exploit them with the XML capabilities of the Oracle database. I hope the beta chapter is interesting and useful to you." See the full description for details. Book ISBN: 1-56592-691-9, 848 pages (est.). Chapter also in HTML format.

• XSLT Reference - From Miloslav Nic. Richly hyperlinked and indexed. See also the Xpath and XSL tutorials.

• [November 13, 2000] "Platform Independent UI Objects. Bringing 'XSL Beans' to the world." By Gavin Thomas Nicol (Chief Scientist, eBusiness Technologies). '10/21/2000.' "XSL Beans are a unique technology for developing UIs that exploits XML and XSL, and that provides a number of benefits, chief of which are: (1) Media independence -- XSL Beans are media independent, meaning that they can be used in Java, Dynamic HTML, or even standard GUI environments. (2) Standards-based -- XSL Beans rely upon, and exploit, XML and related standards, providing an open UI framework. (3) Intelligent data -- XSL Beans rely upon, and take advantage of, intelligent data. In particular, well-designed XML instances make it easy to bring sophisticated application behavior to documents in a transparent manner. (4) Documents as applications -- using XSL Beans, any document can be brought to life as an application, bringing new dimensions of reuse to ostensibly static data. (5) Reusability -- a direct effect of the above two points is that XSL Beans can be reused easily, in new ways. XSL Beans could lead to entirely new ways of approaching old problems, such as forms handling. (6) Instance syntax independent -- a number of different XML instances can result in ostensibly the same UI, resulting in maximum flexibility in data representation. (7) Human legible, human editable -- a direct result of the above is that XSL Bean instance data can be understood, and edited by people with little skill beyond that required for authoring XML documents. This brings application development within the realm of document authors (programming for the masses). (8) Ease of use -- in combination with a UI builder, XSL Beans can be easy to use. More importantly, they can be easy to use even without a UI builder. (9) Flexibility -- XSL Beans are entirely data-driven, meaning that components can change the data format, or the way the data format is interpreted, easily, at any time. XML Beans could play a significant role in many areas, and could revolutionize the document-centric application arena. This paper describes the thoughts leading to the XSL Bean concept, and the XSL Bean concept in detail. The primary purpose of this document is to provide a background to development groups that might be producing cross-platform UIs (in particular, WWW-based UIs) or UI builder applications that could benefit from XSL Bean technology. The paper explains the XSL Bean concept at a fairly high level. There is a companion paper discussing development environments using XSL Beans, which also discusses some parts of XSL Beans in more detail. Also in PDF format. See also the web site: "The basic idea of XSL beans is to use XML/XSL for instantiating objects. The idea in itself is based upon work I did back in the early 1990's on distributed hypermedia. The papers here were written as internal whitepapers, and with permission, I have been able to make them public." [cache]

• [November 13, 2000] "UI Development Using XSL Beans. Discussion of Application Development Environments With A Focus On XSL Beans." By Gavin Thomas Nicol (Chief Scientist, eBusiness Technologies). '11/10/1998.' "In a companion paper 'Platform Independent UI Objects' [see above], the author introduced XSL Beans, a technology that allows UI's to be instantiated using different display technologies, and different object systems. It is assumed that the reader is familiar with the XSL Bean concept. The following is a summary of the advantages of the approach outlined in that paper: (1) XSL Beans are platform independent. (2) XSL Beans are standards based. (3) XSL Beans allow documents to be brought to life as applications. (4) XSL Beans exploit intelligent data, bringing new dimensions of reuse. (5) XSL Beans are flexible. (6) XSL Bean instances can be authored and understood by authors. (7) XSL Bean are easy to use. This paper discusses application development environments, and the background issues associated with them. The intent of this paper is to provide a basis for discussion and development of an application development environment and in particular, one that is compatible with the XSL Bean approach to UI instantiation. Some possible deployment strategies are also discussed in later sections... Summary This paper has looked at WWW applications and development environments for them. The main points can be summarized as follows: (1) Development environments should provide a comfortable and productive environment for the majority of users, and provide some escape hatches for 'power users' so that they do not feel constrained by the environment. (2) The basic paradigm for a development environment should be something akin to Visual Basic: basically the drag and drop, property editing paradigm. (3) A convenient and powerful GUI layout paradigm for the WWW is that of boxes and glue, as found in TeX. (4) Application behavior can be edited directly within a development environment, but doing this well depends on a functional scripting language. (5) XML can be used as the syntax for defining a functional language. (6) The notion of closure, and environments, is crucial to application development environments, and provides a good conceptual framework for managing WWW Application State (7) The most likely development strategy is to develop the environment internally, though purchasing the rights to one is obviously preferable..." Also in PDF format. [cache]

• [September 29, 2000] "XSL Formatting Objects." Chapter 15 of the XML Bible, by Elliotte Rusty Harold. Announcement posted September 30, 2000. "I'm happy to announce that I've posted a completely updated version of Chapter 15 of the XML Bible, XSL Formatting Objects, at Cafe con Leche. This is the complete chapter, approximately 70 pages with many full examples of XSL-FO. Everything should be up-to-date with the March 27, 2000 Last Call working draft of the XSL-FO specification and FOP 0.14.0. To the best of my knowledge, this is the only comprehensive tutorial covering the current version of XSL-FO. Doubtless there are some errors since I was breaking new ground here and had to work from an incomplete and sometimes contradictory spec document, as well as using unfinished pre-alpha software. Since this is more-or-less what's going to go into the second edition of the XML Bible, as well as likely being the primary source for many new users learning XSL-FO, I'd very much appreciate it if you can inform me of any mistakes you spot so I can fix them." Intro: "XSL Formatting Objects (XSL-FO) is the second half of the Extensible Stylesheet Language (XSL). XSL-FO is an XML application describing how pages will look when presented to a reader. Generally, a style sheet uses the XSL transformation language to transform an XML document in a semantic vocabulary into a new XML document that uses the XSL-FO presentational vocabulary. While many hope that Web browsers will one day know how to directly display data marked up with XSL formatting objects, for now an additional step is necessary in which the output document is further transformed into some other format such as PDF.

• [August 22, 2000] "What is XSLT? [XSLT Tutorial, Part One.]" By G. Ken Holman. From XML.com. (August 16, 2000). [Edd Dumbill says: "I'm delighted to publish this comprehensive introduction to the W3C's extensible stylesheet technology from the universally respected XSLT expert, G. Ken Holman. This week and next, Ken will take us through both XSLT's place in the world of XML standards and its practical applications. The first three sections of "What is XSLT?", published this week, introduce XSLT and XPath -- the concept of styling structured information and architectures for applying XSLT stylesheets."] "Now that we are successfully using XML to mark up our information according to our own vocabularies, we are taking control and responsibility for our information, instead of abdicating such control to product vendors. These vendors would rather lock our information into their proprietary schemes to keep us beholden to their solutions and technology. But the flexibility inherent in the power given to each of us to develop our own vocabularies, and for industry associations, e-commerce consortia, and the W3C to develop their own vocabularies, presents the need to be able to transform information marked up in XML from one vocabulary to another. Two W3C Recommendations, XSLT (the Extensible Stylesheet Language Transformations) and XPath (the XML Path Language), meet that need. They provide a powerful implementation of a tree-oriented transformation language for transmuting instances of XML using one vocabulary into either simple text, the legacy HTML vocabulary, or XML instances using any other vocabulary imaginable. We use the XSLT language, which itself uses XPath, to specify how an implementation of an XSLT processor is to create our desired output from our given marked-up input. XSLT enables and empowers interoperability. This XML.com introduction strives to overview essential aspects of understanding the context in which these languages help us meet our transformation requirements, and to introduce substantive concepts and terminology to bolster the information available in the W3C Recommendation documents themselves." [From Crane Softwrights Ltd. published commercial training material titled Practical Transformation Using XSLT and XPath.]

• [August 28, 2000] "Getting Started with XSLT and XPath." By G. Ken Holman. From XML.com (August 23, 2000). ['In the second part of his comprehensive introduction to XSLT and XPath, G. Ken Holman examines practical stylesheets and explains the various approaches to writing XSLT. Using example stylesheets, Ken covers the basic syntax of XSLT and the common patterns of stylesheet design.'] "Examining working stylesheets can help us understand how we use XSLT and XPath to perform transformations. This article first dissects some example stylesheets before introducing basic terminology and design principles. Let's first look at some example stylesheets using two implementations of XSLT 1.0 and XPath 1.0: the XT processor from James Clark, and the third web release of MS Internet Explorer 5's MSXML Technology Preview. These two processors were chosen merely as examples of, respectively, standalone and browser-based XSLT/XPath implementations, without prejudice to other conforming implementations. The code samples only use syntax conforming to XSLT 1.0 and XPath 1.0 Recommendations and will work with any conformant XSLT processor...

• XPATH Cheat Sheet. Links to XPath tutorials and related materials.

• [August 07, 2000] XSLT Stylesheets - Useful things and other jokes. Oliver Becker, System Architecture, Department of Computer Science, Humboldt University Berlin. E.g., (1) An XML to HTML Verbatim Formatter with Syntax Highlighting; (2) A prime numbers computing stylesheet (Sieve of Eratosthenes); (3) An XSLT Loop Compiler that translates iteration elements inside of stylesheets into recursive XSLT template calls; (4) A transformation sheet that merges two XML documents. All the XML documents provided are rendered additionally with xmlverbatimwrapper.xsl for viewing with a pure HTML browser - the link is named '(pretty HTML)'.

• "XSL: XML with Style." By Paul Grosso (VP Research, ArborText, Inc.) Pages 227-230 in SGML/XML '97 Conference Proceedings, Alexandria, VA: Graphic Communications Association (GCA), 1977. See the bibliographic entry for an abstract, or the proceedings volume for the full text.

• "XSL - A Proposed Stylesheet for XML. Placing XSL into Perspective." By Paul Grosso. August 29, 1997. From the 'XML and SGML Library' at ArborText. The paper discusses: "Where XSL fits into the XML specification effort, Where XSL fits into SGML and related technology, Relationship of XSL to DSSSL, Relationship of XSL to HTML and CSS," etc. [local archive copy]

• [April 20, 2000] "Style Matters: Architectures for Styling." By Didier Martin. From XML.com. (April 19, 2000). ['How should you style your XML? Client-side or server-side? CSS or XSLT? Didier Martin presents an exploration of architectures for styling your XML.'] "...in order to view an XML document, it has to be transformed into objects that our senses can perceive -- this transformation process is called styling. This transformation can occur either on the server side or on the client side. The same XML document may be presented in many different ways. On a cellular phone, where only a few lines of text are available, the XML document is not displayed in the same way as it would be with a desktop computer browser. Thus, the appearance an XML document takes depends on the client user-agent we are using to render it. Some user agents may transform the document into an aural experience, others into a visual or a tactile experience. So, where should styling occur? In the user-agent, or before the user-agent ever receives a document? Should we use XSLT or CSS? We'll examine the possible combinations of styling languages and processing models. [...] XSLT allows either server side or client side styling. It also offers one to many mappings between XML objects (element, attributes, etc.) and formatting objects. Multiple views can be created from a single XML document, even if these views require a re-ordering or modification of the document's tree structure. CSS is closely mapped to the XML document structure. Some document views are impossible to create with CSS. CSS does not allow distributed processing, it is a client side only styling engine. However, it is a great complement to certain rendering languages like XHTML, HTML or SVG."

• "XSLTVM - an XSLT Virtual Machine." By Anguel Novoselsky and K. Karun. Presented at XML Europe 2000. "The emergence and popularity of XML helps facilitate the development and integration of business and application semantics. However, each enterprise defines their own data elements to better communicate the 'meaning' of their data. Translation will therefore be key for interoperability. XSL standards for transformation are sufficient to allow exchange between business vocabularies. Currently there are many XSLT engine implementations. In this paper, we present a novel approach for implementing transformations using XSL. We describe a XSLT Virtual Machine (XSLTVM). XSLTVM is the software implementation of a 'CPU' designed to run compiled XSLT code. A concept of virtual machine assumes a compiler compiling XSLT stylesheets to sequence of byte codes or machine instructions for the 'XSLT CPU'. This approach clearly separates compile-time from run-time computations and specifies an uniform way of data exchange between instructions by defining a common interface areas like stack or pipeline for example. The separation line between compile-time and run-time computations depends on the level of machine instructions. Splitting a heterogeneous, high-level instruction into number of atomic, low-level instructions exposes some run-time checks and allows compiler to take care of them. For example, a general CMP instruction checks operand types at run-time. If it is replaced with few type specific CMPs then compiler checks operand types at compile-time and generates appropriate type casting instructions if needed."

• [January 19, 1999] "The Extensible Style Language. Styling XML Documents." By Norman Walsh. In Web Techniques Volume 4, Issue 1 (January 1999). "From the very beginning of the XML effort, it was recognized that in order to successfully send XML documents over the Web, it would be necessary to have a standard mechanism for describing how they were to be presented. That's why we need style sheets. The Extensible Style Language (XSL) is the style language for XML. At the time of this writing (October 1998), XSL is under active development by the W3C. On August 18, 1998, the XSL Working Group (WG) released its first Working Draft. This article introduces XSL as described in that document. . . There are many important and complex issues that must still be resolved, among them: interactivity, support (if any) for a more powerful scripting language, further harmonization of the formatting object semantics, and the definition of many additional formatting objects." [cache]

• [July 26, 1999] "XSLT in Perspective". By James Clark. Slides (HTML) from a presentation given by James Clark in July, 1999. [Per a posting to XSL-List, Sun, 25 Jul 1999.]

• [June 13, 2000] Magically Storming the Gates of Buddhahood: Extensible Text Technology (XML/XSLT) as a Simulacrum for Research." By John Robert Gardner. In International Journal of Tantric Studies (IJTS) Volume 4, Special issue (June 2000) [ISSN: 1084-7553]. "An (un)surprising conceptual parallel between Tantric and Vedic practices of mantra manipulation, and the very latest in computer information technology -- XML, or Extensible Markup Language -- provides scholars with unique new research possibilities. The well-known procedures by which mantras are selected and extracted for ritual application -- e.g., vidhaana -- as well as transposition and intertwining -- e.g., viharaNam -- can be almost directly translated into a powerful new computer tool, called Extensible Stylesheet Language for Transformations (XSLT) and used on electronic versions of shrutii. The paper draws upon these functional parallels to introduce the reader to XML -- which is very much like HTML -- and then demonstrate the theory and application of ideas like viharaNam and vidhaana with electronic texts (full set is included with technical appendices) from the Rig Veda (specifically RV 3.62). Basic theory of XML, XSLT and XPath are introduced, explanations and links to required files and programs (all freeware), and a complete electronic Rig Veda in XML, with pre-written, adaptable XSLT scripts are included. . . This article explores potential of electronic text technology, specifically Extensible Markup Language (XML) and Extensible Stylesheet Language for Transformation (XSLT), in the study of mantra and text resources. The reader should know that due to the necessity for clear explanation of this technology a detailed, incisive, and otherwise comprehensive treatment of mantra theory must remain secondary. Not unlike the competing demands for developmental time that a scholar of the humanities finds when trying to add digital technology to their arsenal of research techniques, this article strives for an appropriate balance. Accordingly, the citations related to mantra use are points of academic reference rather than a suggestion of rhetorical conclusiveness. In the present document, the phenomenon of mantra presentation-specifically Vedic and Tantric-will serve as analog and a source of examples in the illumination of the new, extensible, text technology for research represented by XML and its related standards. There is a great deal more to the technology and related tools for working with XML than the basic outline of its primary characteristics presented below..." [Note: John also wrote on XML-L: "As introductory materials can be hard to find--all in one place, and which go beyond just the abc's of tagging, and for free with support files--I'm bordering on self-promotion by drawing readers' attention to the following publication of applied XML/XSLT in a text-based usage (academia with Mantra studies and Sanskrit, actually, but knowledge of the field is not required). See the endnote."] [cache]

• [September 01, 2000] XML Tutorial 3: XSL Transformations." By Bonnie SooHoo. From Webreview.com (September 01, 2000). "XML allows us to build arbitrary tag sets to describe our data, and writing a well-formed XML document gives relational structure to our data. But how do we deliver that data in a presentable manner people can use? While CSS is one option for adding style, there's another style sheet language built from XML that was designed for this very purpose, called XSL, or eXtensible Style Language...XSL originally consisted of two parts: one for transforming XML documents into other types of documents, and the other part for formatting objects used to format a document. These two parts have since evolved into separate specifications with the XSL transformations part being referred to as XSLT -- that's the focus for this tutorial. The XSL formatting language is still under development; as such, it currently has little support. For those of you who are professing XML to be too impractical for real use because of limited browser support, XSLT comes to the rescue. XSLT offers incredible capabilities for transforming raw XML data into another type of document, such as a well-formed HTML document that should be accessible by everyone. This is basically how it works: An XSL processor takes an XML document and applies the XSL style sheet to it to generate a third source as the transformed output, which is the final product that users will actually see. For this tutorial, this output will be HTML. . ."

• [April 28, 2000] XSLT Programmer's Reference. By Michael Kay. Wrox Press, (April) 2000. 600 pages. ISBN: 1861003129. "My book, XSLT Programmer's Reference, published by Wrox Press, is now available. This is the only book currently available that is completely dedicated to XSLT and XPath." [XSL-List 2000-04-28] Publisher's blurb: "XSL (eXstensible Stylesheet Language) is the styling language to match XML. At the most basic level it allows the programmer to manipulate XML on a template model -- XSL provides the template to fit XML data into for displaying on a web page. However, it is capable of much more than that, and allows programmers to selectively query, display and manipulate data, perform scripting-like operations on the XML document and transform it into pure HTML for use on browsers which don't support XML. [Features:] (1) Covers the most up-to-date W3 XSL recommendations; (2) Includes a no-nonsense tutorial; (3) Extensive reference for XSL support in the most popular browsers; (4) Details of using XSL to manipulate XML on the server; (5) Explains how to extend XSL to suit your needs." See also the 'Source Code for XSLT Programmer's Reference.' See Amazon.com.

• [January 12, 2000] XSLT and XPath Quick Reference Available. A posting from Tony Graham (Mulberry Technologies, Inc.) to the XSL-List announces the availability of a "PDF file for an XSLT and XPath Quick Reference" on Mulberry's quick references page. Tony writes: "The card was developed in support of our XSLT training course, but is now made freely available. The quick reference card is U.S. Legal (8.5" x 14") size. [Note that] we also have an XML syntax quick reference accessible from that page."

• [April 03, 2000] "Hands-on XSL: XSL for Fun and Diversion." By Don R. Day (Advisory Software Engineer, IBM). March 2000. "This article presents a simple, hands-on exercise that demonstrates the principles of the Extensible Stylesheet Language Transformations (XSLT). It takes about an hour to complete the concept exercises and about 15 minutes at a computer to try out the results with a real XSLT processor." Also in PDF format. See also "Darwin Information Typing Architecture (DITA XML)."

• [January 22, 2000] "XSLT Terminology Clarification." Source: W3C Recommendation 16-November-1999. Revision: Draft 0.c. January, 2000. Maintained by Dave Pawson. "Editor comment: These definitions are meant to be explanatory rather than exact. For precision, see the W3C recommendations. They are the the clearest definitions I have... until someone mails me a better one."

• [June 28, 2000] "Getting Value from XSL Parameters." By Kurt Cagle. Microsoft 'Extreme XML' Column. (June 23, 2000). ['In the latest Extreme XML column, guest writer Kurt Cagle examines how variables and parameters can significantly expand what you can do with XSLT, exposing ways to make your style sheets a lot more dynamic. Guest writer Kurt Cagle is filling in this month while regular columnist Chris Lovett is on vacation.'] "When I started playing with the older XSL (the one based on Microsoft's December 1998 submission for XSL and XML Patterns), I quickly realized how much power it had to radically simplify the production of output code. An XSL filter (as I call the stylesheets) could turn a database call into a table, could safely incorporate boiler-plate HTML code, and could even perform simple processing tasks. However, XSL had some limitations for serious, heavy-duty lifting. The biggest issue was parameters; there was no clean way to change an XSL structure without having an intimate acquaintance with the underlying code in the stylesheet. All too often, the only way around passing information into an XSLT transformation was to put parameters on the XML input. Another issue was retaining information internally about the current state of the processor. If you had XML markup that would be sent to the output stream, you couldn't save it temporarily and use it in more than one place. Finally, there was no real way to save state within the XSL environment itself; you had to take the results from the XSL transformation, filter that out with a document object model (DOM) call, and effectively lose any intermediate states that may have taken place within the filter. The Technology Preview XML parser provides support for the newer XSL-Transformation specification (located at http://www.w3.org/TR/xslt). This newer spec contains a number of innovative features that together make XSLT far more capable than Microsoft's December 1998 version of XSL. The spec also makes XSLT a serious competitor for scripting languages as a server tool. In addition to this, Microsoft has also introduced a new way to integrate scripting code (one that is compliant with the W3C standards, by the way), which may end up changing the way we think about server-side programming altogether. . ."

• [August 21, 2000] "Inside XSL-T." By Michael Classen. From WebReference.com (August 2000). ['XML may be all the buzz, but a lot of the heavy lifting is actually done with XSL. Extensible Style Sheet Language Transformation sounds like a mouthful, but XSLT is your key to converting XML documents into display languages like HTML.]' "XSL was initially devised to solve two problems: (1) Transforming an XML document into something else. (2) Formatting an XML document for display on a page-oriented device, such as a printer or a browser. Subsequently it has proven difficult to solve the second problem in a fashion that satisfies all the different requirements from low resolution screen displays all the way to hi-res printing and copying. Furthermore, screen formatting is currently done with Cascading Style Sheets (CSS), so little interest developed in yet another method. The World Wide Web Committee (W3C) then decided to split the two tasks into separate sub-standards, XSL Transformations (XSL-T) and XSL formatting objects (XSL-FO). While XSL-T has been an official recommendation since November of last year, XSL-FO is still in the making. A transformation expressed in XSLT describes rules for transforming a source tree into a result tree. The transformation is achieved by associating patterns with templates. Whenever a pattern matches elements in the source tree, a template is used to create part of the result tree. The result tree is separate from the source tree, and their structures can be completely different. In constructing the result tree, elements from the source tree can be filtered and reordered, and new elements can be added. A transformation expressed in XSLT is called a stylesheet in the case where XSLT is transforming into a display language, such as HTML or WML..."

• [August 10, 2000] "Processing Inclusions with XSLT." By Eric van der Vlist. From XML.com (August 11, 2000). ['Processing document inclusions with general XML tools can be problematic. This article proposes a way of preserving inclusion information through SAX-based processing.'] "The consequences of using more than one file to create an XML document, or XML inclusion, is a topic that enflames discussion lists, and for which finding a general solution is like trying to square the circle. In this article, we will show how customized parsers can expose a more complete document model through an SAX interface and help process compound documents through standard XML tools such as XSLT. Most of the XML APIs and standards are focused on providing, in a convenient way, all the information needed to process and display the data embedded in XML documents. Applied to document inclusions, this means that XML processors are required to replace the inclusion instruction by the content of the included resource -- this is the best thing to do for common formatting and information extraction tasks, but results in a loss of information that can be unacceptable when transforming these documents with XML tools. This topic has been discussed a number of times on different mailing lists, and the feeling of many can be summarized by a post from Rick Geimer on the XSL List..."

• [November 06, 2000] "Transforming XML: Combining Stylesheets with Include and Import." By Bob DuCharme. From XML.com (November 01, 2000). '[XSLT provides two means of combining multiple stylesheets into one, include and import. This article explores the use of these instructions and shows how they can be used to customize the DocBook XSLT stylesheets.'] "The xsl:include and xsl:import instructions give you ways to incorporate XSLT stylesheets programmatically. There are two situations where this is useful. (1) Large, complex stylesheets, like large complex programs, are easier to maintain when you break them into modules with specific roles to play. In XSLT, the xsl:include and xsl:import instructions let you assemble the pieces. This modular approach also makes it possible to share parts of a stylesheet with other stylesheets that only want certain features and not the whole thing; they can just include or import the parts they need. (2) Customizing an existing stylesheet without actually editing that stylesheet is easy, because you incorporate it, and then separately override any template rules that don't do exactly what you want..."

• [August 04, 2000] "Transforming XML: Adding New Elements and Attributes." By Bob DuCharme. From XML.com (August 02, 2000). ['This month's installment of our XSLT tutorial covers adding new elements and attributes to the results of your XSLT transformations.'] "In the first "Transforming XML" column, we saw how an XSLT style sheet can instruct an XSLT processing program to copy, delete, and rename elements being copied from the input to the output. Another common task is the addition of new elements and attributes to the output. Whether you're converting an element to a new attribute, an attribute to a new element, or supplying either with a function's return value or a hardcoded string, you can choose between a quick simple way and a more complex and powerful way to add both elements and attributes to your output. An XSLT processor's main job is to look through a style sheet for the various specialized elements from the XSLT namespace and to execute the instructions specified by those elements on the tree where the input document is stored in memory. When the processor finds elements from outside of the XSLT namespace in any of a style sheet's templates, it passes them along to the result tree and eventually to the output document. We call these 'literal result elements.' This makes it easy to add new elements to your output documents: simply add elements from outside of the XSLT namespace inside of the appropriate templates. (If you really want to output elements from the XSLT namespace--for example, to generate style sheets as output--you'll need XSLT's namespace-alias element.) The following XSLT style sheet demonstrates this. . ."

• [August 31, 2000] "Transforming XML: HTML and XSLT" By Bob DuCharme. From XML.com. August 30, 2000. ['While HTML isn't an XML application itself, it can be both generated and transformed using XSLT. Bob DuCharme show us how.'] "HTML Web pages have played a big part in electronic publishing for some time now, and will continue to for several years. If you use XSLT as a system development tool, you may work on an application that needs to read or write HTML. If your application is reading or writing the HTML flavor known as XHTML, a W3C Recommendation that describes itself in its spec as 'a reformulation of HTML 4 as an XML 1.0 application,' then there's nothing special to worry about: XHTML is perfectly good XML, just like anything else that XSLT can read or write. If your application is reading older legacy HTML or outputting HTML for use in older browsers, however, there are a few small problems to keep in mind and some simple techniques for getting around these problems. HTML as Input XSLT processors expect their input to be well-formed XML, and although HTML documents can be well-formed, but most aren't. For example, any Web browser would understand the following HTML document, but a number of things prevent it from being well-formed XML... Between Dave Raggett's Tidy program and the xsl:output element, you should be all set to incorporate old-fashioned HTML into your new XSLT-based systems!"

• [September 15, 2000] "Transforming XML: XSLT, Comments and Processing Instructions." By Bob DuCharme. From XML.com (September 13, 2000). ['XSLT isn't just for transforming elements and attributes. In this month's Transforming XML column we show how to create and transform processing instructions and comments too.'] "XSLT includes built-in template rules to copy the text element content from a source tree to a result tree. Comments and processing instructions, however, get left out of this; unless you specify otherwise, an XSLT processor ignores them. You can specify otherwise, and this ability gives you access to the potentially valuable information they store. You can also add comments and processing instructions to your output, which lets you store information that wouldn't otherwise fit into your document. This ability to both read and write comments and processing instructions lets you copy comments and processing instructions from your source tree to your input tree and even to convert them to elements."

• [October 21, 1999] "XSLT: Transforming XML." By Bob DuCharme. In <TAG> Volume 13, Number 9 (September 1999), pages 5-6. "XSLT is pure XML: you specify how to convert one document type into another by creating a special type of XML document. XSL offers various specialized element types and attributes to specify different tasks you want performed, and you need to get familiar with them before XSLT will do what you want... The real advantage of representing transformation specifications as XML documents is that this is a closed system. XSL stylesheets define transformations in XML terms, just as the schema for relational database tables are themselves relational database tables. So what does XSLT look like? [...] In the next issue we will look at some of the fancier transformations possible with XSLT such as changing element order, converting attributes to child elements and vice-versa, string manipulation, comment generation, and sorting. These and other features make this budding standard a very powerful, promising contribution to the XML world..."

• [October 06, 2000] "Transforming XML: Finding Relatives." By Bob DuCharme. From XML.com (October 04, 2000). ['XML nodes have many friends and relations. In XSLT, the key to finding them is XPath. In this article Bob DuCharme shows you how.'] "When your XSLT processor is processing one node of your source tree, and you want to get something from another node, you can use an XPath expression and an xsl:value-of instruction. I'm going to hurry through the general structure of an XPath expression to get to the really useful stuff: using XPath abbreviations to get at the different 'relatives' a node can have on a source tree -- siblings, a parent, grandparents and so on. This brief review of the full XPath syntax will put the abbreviations in context. An XPath expression consists of one or more location steps separated by slashes. Each location step consists of an axis specifier, a node test, and an optional predicate. You don't have to include an axis specifier, either; if you leave it out, a default of child is assumed. This makes a node test name like 'product' a perfectly valid one-step XPath location step -- in fact, it's a perfectly valid XPath expression. When you include an axis specifier, it's separated from the node test with two colons, and a predicate goes inside of square brackets, so a location step of preceding-sibling::item means "of all the nodes in the preceding-sibling axis, I want the ones named 'item'." A location step that includes a predicate, like preceding-sibling::item[1], means "of all the nodes in the preceding-sibling axis, I want the first one named 'item'." XPath offers abbreviations that let you use much of its power without spelling out full location path steps every time you want to use them. For example, @ means the same thing as attribute:: and .. means the same thing as parent::node(). Let's see how useful these abbreviations can be and how much more flexibility you have when you use axes that have no abbreviations..."

• [January 04, 2001] "Transforming XML: Axis Powers: Part Two." By Bob DuCharme. From XML.com. January 03, 2001. ['Part one of this series introduced the role of XPath axes in XSLT. This article explains the remaining axes and shows how to handle namespaces in XPath.'] "In part one of this two-part column on 'Transforming XML', we looked at the role of axes in the XPath expressions that are used so often in XSLT stylesheets, and we looked more closely at the child, parent, ancestor, ancestor-or-self, following-sibling, preceding-sibling, and attribute axes. In this column, we'll examine the remaining axes offered by the XPath specification and see what they can do in XSLT stylesheets. The preceding and following Axes: The preceding and following axis specifiers let you address nodes that aren't necessarily siblings. The preceding axis contains all the nodes that end before the context node begins, and the following axis contains all the nodes that begin after the context node ends. We'll use these axes in a template rule for this sample document's test elements. We want this template to add messages naming the titles of the preceding and following chapters. [...] Some XPath axes are more popular than others, so popular that many XSLT developers don't realize that there are 13 in all for use in XPath expressions. Play around with all of them (you can download the examples shown in this column here), and you'll find that the lesser-known ones can often solve your thornier XPath problems..."

• [December 20, 2001] "Axis Powers: Part One." By Bob DuCharme. From XML.com. December 20, 2000. "XPath expressions play an important role in XSLT because they let stylesheet instructions flexibly identify the parts of the input document -- or, in XSLT terms, the nodes of the source tree -- to act on. Let's review the basics. An XPath expression consists of one or more location steps separated by slashes. Each step consists of an axis specifier, a node test, and an optional predicate. For example, the one-step XPath expression following-sibling::para[3] uses an axis of following-sibling, a node test of para, and a predicate of [3] to identify the third para element of the nodes in the context sibling's following-sibling axis. (The context node refers to the source tree node that the XSLT processor is currently dealing with -- usually because it's one of the nodes named by the xsl:template element's match condition or by an xsl:for-each instruction's select attribute.) The two-step XPath expression child::wine/child::prices contains the prices children of any wine children of the context node. In this two-part column, we'll examine the various axes you can use and their potential role in XSLT transformations. [...] In the next column, we'll look at the remaining axes: preceding, following, descendant, descendant-or-self, self, and namespace. Meanwhile, you can play with the examples shown in this column by downloading the zip file ."

• [October 21, 1999] "XSLT: Transformation von XML-Dokumenten." By Henning Behme. In iX - Magazin für professionelle Informationstechnik (October 18, 1999) [Web-Programmierung]. "Fast zwei Jahre, nachdem das W3C die Syntax von XML festgeschrieben hat, sieht es aus, als stünden Teile der Formatierung vor dem Abschluss. Bei XSLT und XPath handelt es sich um die Entwürfe f|r die Dokumententransformation von einer in die andere Struktur..."

• [October 20, 1999] G. Ken Holman has announced the publication of the fifth edition of XSLT/XPath tutorial materials, Practical Transformation Using XSLT and XPath (XSL Transformations and the XML Path Language) [Fifth Edition, 1999-10-14. ISBN: 1-894049-02-0. 288 pages, subscription price includes free updates. Copyright (c) 1999 Crane Softwrights Ltd.] New in this fifth edition: "(1) All constructs of the W3C Proposed Recommendations for XSLT and XPath are documented; (2) New examples and illustrations have been added to old material as well as new; (3) The material is supplied in ten different renditions; (4) The reference annexes in the free preview excerpt download have been updated to the PR and to the latest version of XT. As with our other editions of this XSLT training material, the purchase of any edition of this publication entitles the customer to any future edition of the same material." In the absence of a bound/print reference work on XSL(T), this publication may now be the most complete resource available.

• [June 11, 1999] A communiqué from G. Ken Holman (Crane Softwrights Ltd.) announces the availability of a third edition publication of the work Introduction to XSLT (XSL Transformations) (1999-06-08; 205 pages; ISBN: 1-894049-00-4). The tutorial Introduction to XSLT (XSL Transformations) is a detailed overview of the Extensible Stylesheet Language Transformations, used as the support material for instructor-led lectures and hands-on courses and future Computer Based Training offerings by Crane Softwrights Ltd. The Third Edition covers the entire 1999-04-21 W3C Working Draft of XSLT http://www.w3.org/TR/1999/WD-xslt-19990421.html with references to James Clark's XT (19990514) and Microsoft's IE5 (5.00.2014.0216). A preview excerpt of the complete text of the first three modules, plus overviews of the other seven modules, is available for free download from Crane's web site in the Commercial Training Materials section. The purchase price ($40.00 US) includes free access to all future editions of the same title, thus ensuring currency with W3C revisions to working drafts and the proposed and final recommendations. New editions are also available periodically based on customer and student feedback."

• [May 21, 1999] Ken Holman (Crane Softwrights) announced an update of his online XSLT Tutorial Material. Produced by Ken as part of the Crane Softwrights Ltd. "Training Programmes and Training Materials," the "Introduction to XSL Transformations" is structured as a collection of tutorial references with detailed examples and quick references to use as supplemental material to published standards and recommendations. The entire set is sold commercially, but the first three tutorial lessons are free. The materials "have been revised to reflect all the constructs of the 19990421 XSLT Working Draft. The material includes the original information on IE5 and its relationship to the 19991216 Working Draft, though the focus of the tutorial is the W3C 19990421 XSLT Working Draft. Working code fragments are included. The free download of the overview pages and the on-line purchase of the commercial materials are available through the link on our website home page. Due to a frequent request of visitors considering purchase, the complete text of the first three modules is now also available to be downloaded for free. The quick index module (Module 2) is quite lengthy as it includes alphabetical listings of the XSLT vocabulary and functions, and a cross-referenced summary of productions. The third module gives an example of the writing style of the remainder of the modules." See also the "testimonial" from Mike Brown regarding four online reference resources for learning about XSLT.

• [July 28, 1999] "Introduction to XSL." By Dr. Miloslav Nic (Department of Organic Chemistry, ICT Prague - VSCHT Praha). July 26, 1999. "I have finished the first version of XSL tutorial. The tutorial is based on individual examples, a reader sees XML source, XSL stylesheet and HTML output on one page. All examples or books are generated from XML sources, it takes about 3-4 min. to write a new example, if you know what you want to deliver. Some indexes are automatically generated. You can see the tutorial at: http://zvon.vscht.cz/HTMLonly/XSLTutorial/Books/Book1/index.html. Download all necessary files at: http://zvon.vscht.cz/ZvonHTML/Downloads/zvonXSLTutorial_en.html and if you would like to contribute, read the instructions in the HELP file. This file describes how the tutorial is generated."

• [October 09, 2000] XSLT Stylesheets for TEI -> HTML/FO Conversion. Sebastian Rahtz (of Oxford University Computing Services) announced two new tools for use of TEI and HTML. The Text Encoding Initiative (TEI) is an international project to develop encoding guidelines for the preparation and interchange of electronic texts for scholarly research, and to satisfy a broad range of uses by the language industries; its SGML/XML DTDs are now used widely in digital library projects within academia and government. Sebastian writes of the new tools: "I have revised and expanded my XSLT stylesheets which transform TEI XML documents to HTML, and to XSL FO. They are documented at http://users.ox.ac.uk/~rahtz/tei/. I have also written a new utility which TEI HTML users may find helpful, at http://quirk.oucs.ox.ac.uk/cgi-bin/tei/stylebear. This is a web form which asks you lots of question about how you want your HTML to look, and then generates an XSLT stylesheet for you. It does this by setting values for the 50 or so variables which are provided for customization of the main TEI HTML stylesheets. I'd be very happy to get feedback on the usefulness of this, and ideas on how to improve it..." These tools are part of the larger suite of "XSL stylesheets for TEI XML," described in the introduction thus: "I have prepared a set of XSLT specifications to transform TEI XML documents to HTML, and to XSL Formatting Objects. I have concentrated on TEI Lite, but adding support for other modules should be fairly easy. In the main, the setup has been used on `new' documents, ie reports and web pages that I have authored from scratch, rather than traditional TEI-encoded existing material. The stylesheets have been tested with the XT, Saxon, Xalan and Oracle XSLT processors; the last of these does not support multiple file output, which means that you cannot use the 'split' feature of the stylesheets to make multiple HTML files from one XML file." Note that Sebastian Rahtz also maintains PassiveTeX, a system using XSL formatting objects to render XML to PDF via LaTeX. On TEI, see "Text Encoding Initiative (TEI) - XML for TEI Lite."

• [November 22, 1999] "XPath Tutorial." By Miloslav Nic (Department of Organic Chemistry, ICT Prague). November 22, 1999. ['XPath tutorial: XPaths are just wonderful. I really hope that they will be used as much as possible so there is my little contribution to their propagation.'] See also the larger collection of 'Zvon' tutorial materials by Dr. Miloslav Nic.

• [December 1999] "Getting Started with XSLT Style Sheets and Java Servlets." By Edd Dumbill. In WebTechniques (December, 1999). "The world of XSL is moving fast, and developers want to know how this technology can benefit them. The XSL Transformations (XSLT) Working Draft has been evolving for the past year and has now reached a point of near stability. There are already several XSLT processors available, all in development in parallel with the Working Draft. The combination of XML and XSLT is a powerful one. Documents can be created in XML, and the HTML presentation can be derived automatically from the original data. This mechanism gives you all the advantages associated with separating presentation from content, notably an easily changeable appearance, and preservation of the original structured content. However, you could accomplish this with Make and Perl, and indeed some developers have been doing it this way for several years. When we add servlets to the equation we can generate parts, or the whole, of our XML document dynamically to produce personalized, database-backed, or otherwise adaptive pages while still maintaining the advantages of separating content and style..."

• [August 26, 1999] Nikita Ogievetsky (President, Cogitech, Inc.) posted an announcement for the availability of slides from the Metastructures '99 presentation "HTML Form Templates with XML. All in One and One for All. XSLT template library for WEB applications." The paper describes building XSLT template library for web applications. The goal was to "demonstrate data processing on the web made easy with XSL transformations: Generate a data maintenance web with data-structure controlled by XML, screen designs and database API controlled by XSL. The principal XML document consists of: (1) XML description of an object, and (2) a sitemap implemented as extended XLink. The HTML and server side scripts are built dynamically by applying XSLT transformations to the XML document. This is successfully implemented in production. To the best of my knowledge it is the first live appearance of extended xlink (including arcs) implementing July 1999 working draft." See also the "Links to other sites serving server-site Scripts with XSLT."

• [July 20, 1999] "XSL Transformations." By Elliotte Rusty Harold. Online presentation. July 20, 1999 [or later]. Chapter 14 of the XML Bible. "The Extensible Style Language (XSL) includes both a transformation language and a formatting language. Each of these, naturally enough, is an XML application. The transformation language provides elements that define rules for how one XML document is transformed into another XML document. The transformed XML document may use the markup and DTD of the original document or it may use a completely different set of tags. In particular, it may use the tags defined by the second part of XSL, the formatting objects. This chapter covers the transformation language half of XSL."

• [June 30, 1999] XSL Slides - Tutorial. By Paul Prescod. 83 slides from a tutorial presentation, including step-by-step examples. [About] 20-Sep-1998.

• [July 19, 1999] DTD for XSLT? "[Anthony Finkelstein:] Are we missing something obvious, or is there really not a valid DTD for XSL(T) in general circulation? [James Tauber:] It is difficult to have a DTD for XSLT because it mixes multiple namespaces (one for the XSLT vocabulary and one for the output vocabulary). XSLT includes a partial DTD but you have to add the markup declarations necessary for the output vocabulary. The XSL formatting objects could have a DTD, but that is not what is included in the XSL spec. The DTD in the XSL spec is a guide for implementers saying (principally) which properties go where. It is an SGML DTD because SGML DTDs are more expressive. Remember that formatting objects aren't principally an XML vocabulary. They are nodes in a tree with properties and just happen to be easily serialised as XML. Ultimately, XSLT and XSL could have schemata in other, more expressive languages (like the schema language the W3C is currently working on) that allow for namespaces..." [XML-L, 17 Jul 1999]

• [June 10, 1999] "Patterns in XSL [Beyond HTML]." By Michael Floyd. In Web Techniques (June 1999) [June 1999 Special Issue XML & Java: An Obvious Match.] Michael Floyd shows you how to use XSL patterns to locate objects within the document tree. "Last month I showed how you can assemble a workbench of XML tools that together will let you serve XML documents from your Web site. One of the tools on that workbench, XML Enabler, is a Java servlet that lets you map an XSL style sheet to a specific browser. This, in turn, lets you attach a style sheet to an XML document that's capable of generating HTML specific to that browser's capabilities. Imagine being able to position a DIV block and have it look the same in Microsoft Internet Explorer 5 and in Netscape Navigator 4, or to be able to render an XML document in any browser, including Lynx. The strength in delivering such documents, as you'll see, comes from the eXtensible Style Language (XSL). There's a lot to XSL, so this month, I'd like to show how you can use patterns to locate objects within the document tree. From there, you'll be able to specify template rules that let you format these objects."

• [March 03, 1999] 'A proposal for the creation of a W3C-recommended transformation language.' By Paul Prescod. ". . .we would like the transformational part of XSL to be specified as a separate entity. We believe that this would strengthen both the transformational and formatting parts of what we now call XSL. . . Please submit your opinion to: http://www.prescod.net/xsl/petition/"

• [May 28, 1999] "A formal model of pattern matching in XSL." By Philip Wadler [Bell Labs, Lucent Technologies, wadler@research.bell-labs.com]. January 8, 1999. "I've written a brief formal description of patterns in XSL. The note presents a formal model of the semantics of pattern matching in XSL. The formal semantics brings to light issues that can be hard to spot in an English language description. For instance, here is how [the XSL specification] defines match: 'The result of the MatchExpr is true if, for any node in the document that contains the context of the MatchExpr, the result of evaluating the SelectExpr with that node as context contains the context of the MatchExpr. Otherwise the result is false.' As James Clark noted, this sentence is ambiguous: does `contains' qualify `document' or `node in the document'? (The intention is the former.) The formal specification given here presents the same information in just one line, and avoids the ambiguity. The semantics is formalized using sets. When a selection pattern is processed using for-each, the selected nodes are presented in document order. We use the usual notation for sets, including set comprehensions. See any standard textbook for an introduction, such as Halmos. . . Also in Postscript format. See the reference page: http://www.cs.bell-labs.com/~wadler/xsl/. See also Tony - a XML Parser and Pretty Printer. [local archive copy]

• [May 04, 1999] "What's the Big Deal with XSL?" By G. Ken Holman. From XML.com. "Confused about XSL and how it relates to CSS? Ken Holman explains that the relationship between XSL and CSS is a complementary one. He examines two different implementations of XSL and provides the documents and stylesheets for you to compare to each other."

• [July 19, 1999] "Objects by Design - Transforming XMI to HTML." By Stuart Zakon. 'Tutorial on using XSL to transform XMI (XML for UML) into HTML'. "In this project we will be demonstrating how to use the newly introduced XSL stylesheet technology to transform XMI documents into HTML. Our purpose is to be able to display an object-oriented design in a web browser. XMI is an XML-based, stream representation of a UML model which has the potential to allow models to be shared between different UML tools. Since XMI is a relatively new part of the suite of UML standards (March, 1999), support for this standard will appear gradually over the course of this year. For a discussion on the future role XMI can play in the O-O development process, please see our criteria for choosing a UML modeling tool. There are a number of new, evolving technologies discussed in the sections which follow. Links to documents describing these technologies are provided at the end of this page for further research. The reader will benefit by delaying the navigation of these links until after the presentation of our design. The main driver of the XML transformation is the XSL processor. The XSL processor reads in both the XML document and the XSL stylesheet. The XSL stylesheet describes a set of patterns to match within the XML document and the transformations to apply when a match is found. Pattern matches are described in terms of the tags and attributes for elements found within an XML document. Transformations extract information from the XML document and format it into HTML. Each match/transformation pair is called an XSL template; we will soon see them in action." See "Object Management Group (OMG) and XML Metadata Interchange Format (XMI)."

• [May 31, 1999] "Stephen Deach - Response to Leventhal's Article." By Stephen Deach (Adobe). A response to the article "XSL Considered Harmful," by Michael Leventhal. Stephen Deach is Editor of the W3C Working Draft Extensible Stylesheet Language (XSL) Specification (21-April-1999). From the author's 'Conclusion': "If XSL provides a better mechanism to support online presentation, it is clearly in the web community's interest. If it provides a better solution to print it is clearly in the web community's interest. If it provides a common mechanism to support print and online presentation it is clearly in the web community's interest. If it does all of these, even better. From preliminary indications, XSL seems implementable and useful, thus Mr. Leventhal's request to stop work on XSL (at least until CSS-2 is fully implemented on every platform) is not only unrealistic, but is detrimental to the web, since it would delay widespread support for XSL." See below.

• [June 11, 1999] From Arbortext's "Think Tank": expert Norm Walsh on various industry and XML related subjects. The first "The XSL Debate: One Expert's View", Norm 'discusses the debate about the merits of XSL and gives his personal opinion on this recently hot topic.' See immediately below.

• [June 11, 1999] "The XSL Debate: One Expert's View." By Norman Walsh. From XML.com (June 09, 1999). 'Norm addresses the recent debate about the merits of XSL. As a member of the XSL committee, he said he found the debate disappointing because it was polarizing. He describes the fundamental principles behind XSL and why it is necessary for a fully functional Web. . .' "Recently, there has been some debate about the merits of XSL (the extensible style language, one of the original family of XML standards). This debate has taken place on several mailing lists and, most recently, was the featured topic on XML.com. My own experience with structured markup and stylesheets is extensive. I've written stylesheets using FOSIs, CSS, DSSSL, and XSL. Before my SGML days, I wrote them in TeX and LaTeX, I dabbled in Troff and my own home-grown formatters generating raw PostScript, and even an old IBM mainframe system called simply "Script". Several people have asked my opinion about the XSL debate, so here it is. What follows are my own observations and my personal feelings about the issue. Mostly, I find the whole debate rather disappointing. Disappointing because much of the debate seems to be framed in the most polarizing language possible and hardly seems designed to engender serious discussion. . ."

• [May 21, 1999] "XSL Considered Harmful." By Michael Leventhal. From XML.com (May 20, 1999). "XSL is far more complicated than it needs to be, and we don't need it, argues Leventhal. CSS and the DOM are just fine so waiting for XSL to become a standard is nothing but a distraction." See also Part 2: "This article demonstrates how a combination of CSS and DOM are sufficient to do what you'd need XSL for." See previously: "Formatting Objects Considered Harmful," By Håkon Wium Lie (Opera Software, Norway). April 15, 1999.

• [March 15, 1999] Sun and Adobe Offer $90,000 Cash Bounty for XSL Implementations. A news report from the San Jose XTech '99 Conference describes three prizes being offered by Sun and Adobe as cash incentives for XSL development. See also the news summary.

• [January 25, 1999] Rick Jelliffe (Academia Sinica, Taipei, Taiwan) has published an interesting paper on "Using XSL as a Validation Language." From the document abstract: "XSL can be used as a validation language. An XSL stylesheet can be used as a validation specification. Because XSL uses a tree-pattern-matching approach, it validates documents against fundamentally different criteria than the content model. This paper gives some examples. XSL can be used on structured documents which do not use markup declarations. And XSL used in consort with XML markup declarations seems a very nice and straight forward approach: two small languages, each good at different things. What is missing? The current XSL does not have some features which would be desirable (how to report the current line and entity, in particular) for a user-friendly system. Regular expression pattern matching on strings would be very useful. (The main thing missing from this note is a definite way to create the message "This file is valid"; validity is shown by an empty list of validity errors.)" And see below.

• [May 20, 1999] "Generating XSL for Schema Validation." By Francis Norton. Version: 1999-05-20. Norton says: 'Inspired by Rick Jellife's note on using XSL to schema-validate XML documents, I have written a note on using XSL to generate such XSL schema validators directly from a schema, illustrated by a minimal example that can work with the IE5 parser. I've also indulged in some speculations about future uses of this approach, together with links to people already working in these directions.' Abstract: "An XSL stylesheet can be used to generate XSL validators from XML schemas. This document outlines the mechanics of this process and speculates on other uses for this technology. . . Why generate Schema Validators automatically? t is possible to code by hand an XSL stylesheet that will validate an XML document against some or all constraints of an XML schema. This note presents the case for generating such Validator stylesheets automatically by transforming an XML schema through an XSL validator-generator. The resulting XSL validator can then be used at run-time to validate XML documents that claim to conform to the original XML schema, returning an XML document that contains a list of invalid elements or is, for a valid document, empty. . . [NB: This note builds directly on the idea of using XSL as a validator for XML Schemas described by Rick Jellife in Using XSL for Structural Validation.]" [local archive copy]

• Hypertext Link Support Requirements for XSL." By Christopher R. Maden. Written originally for the World-Wide Web Consortium XSL Working Group. Revision 0.2, 12 May 1998. Abstract: "The XLink and XPointer specifications provide a level of hypertext functionality that has not previously been available for widespread use. To succeed as a stylesheet language under these new conditions, XSL must address certain styling problems introduced by rich hypertext, including stylistic treatment of link ends and styling of transcluded text." The document represents only [the author's] thoughts on the subject, and has not been voted upon or endorsed by the XSL WG. [local archive copy]

• "An Introduction to XSL." [Slides from] a presentation to the SGML UK Users' Group, by Henry S. Thompson (HCRC Language Technology Group, University of Edinburgh). October 27, 1997. Cf. Henry Thompson's "A Hands-On Guided Tour of 'A Proposal for XSL'," December 12, 1997, at SGML/XML '97. [local archive copy]

• [February 18, 1999] "Using XSL to Sort and Filter Your Data." By Charlie Heinemann. In Extreme XML [A Monthly Column on Using Extensible Markup Language] (February 08, 1999). "In past articles, I've described ways to use Extensible Stylesheet Language (XSL) to transform XML into HTML for display. There are, however, other fine uses for XSL. It can be used to transform your current XML into new XML. You can use XSL to transform existing XML into different formats for different applications. I will show you how to use the sorting and filtering capabilities of XSL in conjunction with the XML Data Source Object (XML DSO) to create a basic data entry Web application. The XML DSO allows a simple declarative method of displaying data. It also has the nice feature of being live with respect to the bound XML document. Using XSL, you can further increase the benefits of the XML DSO and have even greater control over what data is displayed and how that data is displayed."

• [February 12, 1999] "The World Wide Web Consortium Statement on US Patent #5860073." By [Contact] Janet Daly. February 08, 1999. "Recently, the U.S. Patent and Trademark Office awarded patent #5860073 for Style Sheet technology. Without complete legal analysis, W3C cannot make a statement regarding how the patent affects style sheet technologies (CSS, XSL) developed within W3C. We do note that Style sheets were used with the first Web browser, and proposals on cascading style sheets arose from CERN in 1994. Further, W3C's own licensing agreements reinforce its open practices."

• [April 19, 1999] "The MetaXSL Engine." By Olivier Brand. From Intraware, Intranet library. [Conclusions:] "With admittedly limited testing, our prototype MetaXSL Engine performs quite well. We tried it with several combinations of XML Parsers and XSL Processors currently available for download and they all worked, although performance varied. These tools are constantly being updated so it is important to build a solution with an open architecture. XML and related technologies and the tools to support them will continue to evolve and mature as all new technologies do. We found that the current state of affairs is suitable to begin prototyping with and we encourage others to begin planning their own prototypes. XML will generate multiple and robust benefits for users and web developers. The smart developers will begin learning how it works now. As for our prototype and goals, we were able to successfully implement a combination of XML/XSL and Java code to achieve our goals. Our prototype has an open architecture, the presentation logic (XSL) is separated from application logic and our performance is better than we expected. In addition we can support localization with a minimum of effort. We also learned a lot about how XML/XSL work and about the current crop of Java tools that support it. It has been time well spent and we plan to continue developing XML ideas in Java. What we've done is just a prototype and none of this has been incorporated into our web site yet, but it provides a solid basis for us to develop upon for eventual production."

• [March 10, 1999] "Sun, Adobe Offer Bounty for XSL." By Paul Festa. In CNET News.com (March 09, 1999). "In an attempt to jump-start XSL development, Sun Microsystems and Adobe are putting up $90,000 in bounties for independent developers who come up with specific XSL implementations. Sun's Jon Bosak, chair of the World Wide Web Consortium's (W3C) XML coordination group, alluded to the prizes during his keynote presentation at the XTech 99 conference here. Bosak said the companies would formally announce the prizes next month. The companies will reveal the winning implementations at the Graphic Communications Association's XML 99 conference, scheduled for the first week of December. The firms plan to eventually put the winning technologies in the public domain. The second part of XSL is its formatting language, and it is this area that Sun and Adobe's incentive prizes are meant to stimulate. Sun will put up $30,000 for implementations of XSL to be added to the Mozilla.org open source effort, developing the source code to Netscape Communications' Communicator browser. This implementation would be a plug-in that would provide XSL formatting capabilities for the Mozilla browser and would fall under the Mozilla public license. The second set of prizes, funded in part by Adobe, will provide a $40,000 first prize and a $20,000 second prize for a print-oriented batch formatter written in Sun's Java programming language and that supports Adobe's portable document format (PDF)." [local archive copy] See also: "Sun, Adobe Offer Cash for Creativity, via XML Development Competitions." By James C. Luh. In Internet World (March 15, 1999). [Canceled; see below]

• [June 18, 1999] XSL Competition Canceled.. From Jon Bosak.

• [March 11, 1999] "DataChannel and XSL: The XSL-based DataChannel RIO Client." By Norbert H. Mikula [Director of Architectural Services, DataChannel, Inc.]. "Stylesheets are instructions that help software transform XML data into a rendered format, visually or non-visually. This white paper discusses XSL, the Extensible Stylesheet Language, an XML-based standard that provides the foundation for visual rendering of XML information. This white paper also presents the XSL-based DataChannel RIO client, a technology preview for XSL-driven user interfaces and the next generation of DataChannel technology.

• [September 16, 1998] "The Style Sheet Landscape." By Jared Sorensen. In The Gilbane Report on Open Information & Document Systems Volume 6, Number 3 (May/June 1998), pages 1-19. ISSN: 1067-8719. Executive Summary: "Creating documents in any form isn't much use if you can't deliver them to people. Style sheets are a key component in document delivery. While they have a long history, a new generation of style sheet technology is just starting to come into play in Intranet and publishing environments. This survey covers the issues that underlie the style sheet problem, some [of] the technologies that are striving for success, and the criteria that are important in deciding which of these to use. . . You can trace the trend towards separating form and content in publishing applications to the early days of computer publishing in the 70s. Even before adventurous souls started using SGML there were proprietary 'generic code' applications and implicit style sheet approaches in use. Today we are all familiar with style sheets whether or not we actually make much use of them -- and of course most of us do not use them correctly! Early SGML applications of course had to do something about formatting. Since there wasn't a standard mechanism in place there were two options: create your own way of applying formatting characteristics to SGML, or incorporate formatting commands directly in the SGML source. The latter approach was unfortunate because it subverted the separation of form and content and made the resulting SGML much less portable, but since there were no standard solutions it is easy to see why this practice had some appeal. In this issue Jared Sorensen provides an overview of the options and expert advice on what you should do. Jared is involved in W3C activity but is speaking from his own experience in using style sheets for Web publishing."

• [September 11, 1998] A document "Using XSL and CSS Together" was submitted by Håkon Lie and Bert Bos as a W3C NOTE. References: NOTE-XSL-and-CSS-19980911, W3C Note, 11 September 1998. The document abstract: "This W3C Note describes how XSL and CSS can be used together. In particular, it discusses how XSL can be used as a bridge between complex XML-based documents and the CSS formatting model. It gives an outline of a system for displaying documents in XML-based formats as human-readable, or human-audible, text. To use the CSS properties in the language of XSL, it is necessary to invent an XML-based syntax, compatible with XSL, to represent CSS's properties. No new CSS properties, or other formatting semantics, are defined in this document." [local archive copy]

• XSL Tutorial Slides. By Daniel M. Germán.

• "XSL Tutorial." From Microsoft. January 7, 1998. Part of Microsoft's 'Technology Preview Release.' In this connection, see Microsoft's [XSL] Overview. [tutorial local archive copy]

• [April 07, 1998] Announcement from Norman Walsh (ArborText, Inc.) for the availability of slides and examples from the XSL Tutorial given by Paul Grosso and Norm at the Seattle XML '98 Conference (March 24, 1998). The slides "were produced from a single SGML source document using a mixture of XSL and DSSSL." This XSL Tutorial is also available from the ArborText Web site.

• [October 30, 1998] "Understanding XSL." By Jay Greenspan. In HotWired Webmonkey (October 28, 1998).

• [April 24, 1998] "DSSSL and XSL." By Tony Graham. Dated 10/16/97.

• [June 04, 1998] "Rendering XML Documents Using XSL." By Sean McGrath. In Dr. Dobb's Journal Volume 23 Number 7 (July 1998) pages 82-85. [ISSN: 1044-789X] "Responsibility for rendering XML belongs to the eXtensible Style Language (XSL) Standard. Sean presents an overview of XSL and illustrates how it can be used with MSXSL, Microsoft's XSL implementation. Additional resources include xsl.txt (listings).

• [April 06, 1998] "Tutorial XSL." [in French at the moment], see also La norme XSL. Par Alain DESEINE.

• [April 03, 1998] XSL Tutorials from Frank Boumphrey. And see: Styling for XML.

• [March 10, 1998] Poster on The Extensible Style Language (XSL), presented by Norman Walsh at SGML/XML '97; [local archive copy]

• "Adding Style and Behavior to XML Pages with a Dash of Spice." Submission to the W3C from Hewlett-Packard Company (HP Laboratories), February 3, 1998, recommending that the World Wide Web Consortium evaluate the proposal as part of the XSL style sheet discussion. Editor: Robert Stevahn. Reference: NOTE-spice-19980123. "Spice is an extended version of the ECMAScript language. . . [being] an amalgam of ideas from DSSSL, CSS and JavaScript." See also the overview and the W3C comment on the Spice Submission. A document comparing Spice and XSL has been written by the submission's editor, Robert Stevahn. [submission, local archive copy]

• [April 16, 1999] "Initial Audio Characteristics for XSL." By Christopher R. Maden. Revision 0.1 7 May 1998, Initial draft. "In keeping with the W3C's mission of accessibility, XSL must make an effort to make accessible documents as easy to create as possible. The more difficult accessibility is to achieve, the fewer documents will be accessible, as authors will not perform extra work to benefit what is often perceived as an insignificant minority. I propose adding audio characteristics derived from Aural Cascading Style Sheets to the otherwise visual flow objects in the July 1998 draft of XSL." [Note of 1999-04-16: In response to David Carlisle ('You make the point about aural rendering. It may be so that once someone implements an aural FO renderer it turns out that what, to the print minded view, seems like a single formatting object ought to be two or more, to cater for aural distinctions, but surely that can be fixed by suitable FO definitions.') Maden wrote: "Exactly my thought. See my proposal, "Initial Audio Characteristics for XSL," at http://www.oreilly.com/people/staff/crism/xsl/. It's a little old, and makes reference to ACSS instead of CSS2, but the principles hold up, I think." [local archive copy]

• "XML, XLL, and XSL: Current Status, Next." By Bob DuCharme ["XML Correspondent"]. In <TAG> Volume 11, Number 1 (January 1998) 1-3. See the third section in the article: "XML Phase III: XSL."

• [February 11, 1998] "Microsoft Releases Preview of XSL Style Processor." By Mark Walter. In The Seybold Report on Internet Publishing Volume 2, Number 6 (February 1998) 29-30.

• [April 01, 1998] "First Baby Steps on The Journey to Working XML. Extensible Stylesheet Language links XML elements to HTML formatting." By Wayne Bremser. In InternetWorld Volume 4, Number 12 (March 30, 1998) page 28.

• [April 03, 1998] Powerpoint presentation on XML Style Language (XSL). By Martin Bryan. Presented to SGML UK (SGML Users' Group) Tuesday, March 31, 1998.

• [April 03, 1998] "The MSXSL XSL Processor." Presentation made by Sean McGrath to SGML UK (SGML Users' Group) Tuesday, March 31, 1998.

---

DSSSL

DSSSL. ISO/IEC 10179:1996 DSSSL (Document Style Semantics and Specification Language) is the principal basis for 'XSL' as described in the Proposal. The collection of sample DSSSL stylesheets will be valuable for understanding several constructs in the XSL Proposal, as will the online DSSSL tutorials by Paul Prescod and Daniel M. Germán.

---

Cascading Stylesheets

CSS. Cascading stylesheets, developed by the W3C Style Working Group. CSS2 is a style sheet language that allows authors and users to attach style (e.g., fonts, spacing, and aural cues) to structured documents (e.g., HTML documents and XML applications). By separating the presentation style of documents from the content of documents, CSS2 simplifies Web authoring and site maintenance."

Other references:

• W3C Cascading Stylesheets - Overview and Reference Collection
• W3C provides resources for CSS2 Validation.
• International Layout in CSS WD-i18n-format-19990127.
• CSS1 Test Suite. See also the announcement: "The World Wide Web Consortium Releases CSS1 Test Suite."
• "List of Suggested Extensions to CSS." NOTE-CSS-potential-19981210

---

Stylesheet Linking

Associating stylesheets with XML documents Version 1.0 W3C Proposed Recommendation 14 January 1999. Edited by James Clark.

Stylesheet Linking. Associating Stylesheets With XML Documents. Version 1.0 WD-xml-stylesheet-19981001. Edited by James Clark. World Wide Web Consortium Working Draft 1-October-1998. "This document allows a stylesheet to be associated with an XML document by including one or more processing instructions with a target of xml-stylesheet in the document's prolog." See the note for a last call for review (deadline: November 17, 1998). [local archive copy]

Stylesheet Linking. [1998-05-09, see previous entry] A proposal for a standard mechanism to associate a stylesheet with an XML document by means of an XML processing instruction is documented in a W3C NOTE, "Associating Stylesheets with XML Documents." The NOTE, authored by James Clark, has been submitted to the W3C at the request of the XML Working Group. The proposed syntax and semantics are analogous to the HTML LINK element used to identity stylesheets, as illustrated in:
  <LINK rel="stylesheet" href="mystyle.css" type="text/css">
  <?xml:stylesheet href="mystyle.css" type="text/css"?>.
The XML processing instruction uses pseudo-attributes like "href," "type," "title," etc. The examples shown in the NOTE are for CSS client-side stylesheets. Document identifier: NOTE-xml-stylesheet-19980405, W3C Note 5 Apr 1998; [local archive copy]

---

DSSSL-o

DSSSL-o. XSL incorporates the subset of DSSSL flow object classes and characteristics specified earlier in DSSSL-o.

---

ECMAScript

ECMAScript. ECMAScript (standardized JavaScript) is referenced in the current XSL proposal as a mechanism for user-extensibility: its scripting capabilities are used to compute and generate text (string data), which then is converted into a flow object. See also: ECMAScript: ECMA-262 JavaScript Language Specification. "A general purpose scripting language (GPSL)", 1997. Available as PDF, or MS Word, in Win 32 self-extracting binary. At least one Free EcmaScript Interpreter is available.

---

XQL

XQL [November 13, 1998] Among the thirteen position papers submitted for QL'98 - The [W3C] Query Languages Workshop as of November 13, 1998 is a proposal for an XML Query Language (XQL) based upon XSL pattern syntax. The paper was authored principally by Jonathan Robie (Texcel, Inc.), Joe Lapp (webMethods, Inc.), and David Schach (Microsoft Corporation), with contributions by Michael Hyman and Jonathan Marsh (both of Microsoft Corporation). The XQL paper proposes to use the XSL pattern language as the basis for a general query mechanism. "The XML Query Language (XQL) is a notation for addressing and filtering the elements and text of XML documents. XQL is a natural extension to the XSL pattern syntax. It provides a concise, understandable notation for pointing to specific elements and for searching for nodes with particular characteristics. This proposal was provided in September 1998 to the XSL Working Group (http://www.w3.org/Style/XSL/Group/1998/09/XQL-proposal.html) as input when considering extensions to the XSL pattern syntax. XQL [thus] builds upon the capabilities XSL provides for identifying classes of nodes, by adding Boolean logic, filters, indexing into collections of nodes, and more. XQL is designed specifically for XML documents. It is a general purpose query language, providing a single syntax that can be used for queries, addressing, and patterns. XQL is concise, simple, and powerful." A companion document by the same authors "Querying and Transforming XML, also submitted as a QL '98 position paper, "describes the benefits of basing query and transformation languages for XML on the XSL transformation language and the extensions to the pattern language proposed here."

---