XSLT Standard Library

Steve Ball


Table of Contents

Preface
1. XML Namespaces
2. Engineering Standards
3. Reference Documentation
String Processing

Preface

The XSLT Standard Library, xsltsl, provides the XSLT developer with a set of XSLT templates for commonly used functions. These are mostly implemented purely in XSLT. Some templates call extension functions provided by XSLT processors, in order to provide a common interface.

Goals of the xsltsl project include:

  • Provision of a high-quality library of XSLT templates, suitable for inclusion by vendors in XSLT processor software products.

  • Demonstration of best practice in XSLT stylesheet development and documentation.

  • Provide examples of various techniques used to develop XSLT stylesheets (ie. a working FAQ).

Chapter 1. XML Namespaces

Apart from the XSLT XML Namespace (http://www.w3.org/1999/XSL/Transform), xsltsl employs a number of XML Namespaces to allow inclusion of the library in developer stylesheets. In addition, documentation is defined in a separate namespace.

Each module is allocated a namespace URI by appending the module name to the URI for the project's SourceForge web page, http://xsltsl.sourceforge.net/. For example, the string module has the namespace URI http://xsltsl.sourceforge.net/string.

All documentation is written using DocBook. The namespace URI for DocBook is http://nwalsh.com/xsl/documentation/1.0

Chapter 2. Engineering Standards

In order to maintain a high engineering standard, all modules and contributions to the xsltsl project must adhere to the following coding and documentation standards. Submissions which do not meet (or exceed) this standard will not be accepted.

  • All stylesheets must be indented, with each level indented by two spaces. NB. a simple stylesheet could be used to enforce/fix this.

  • Templates are named using a qualified name (QName). The namespace URI for the template's containing stylesheet is assigned as above.

  • Parameters for templates should use sensible names. Where possible (or if in doubt), follow these conventions:

    • A parameter containing a single node is named node. Where more than one parameter contains a single node, the suffix Node is appended to the parameter name, eg. referenceNode

    • A parameter which potentially contains multiple nodes is named nodes. Where more than one parameter potentially contains multiple nodes, the suffix Nodes is appended to the parameter name, eg. copyNodes

    • A parameter which contains a string value is named text.

  • All templates in each stylesheet must be documented. A template is documented as a DocBook RefEntry.

  • Every stylesheet must include a test suite. The test system is in the test subdirectory. See test/test.html for further details.

Chapter 3. Reference Documentation

Table of Contents

String Processing

Reference documentation is available for each module.

String Processing