>XSLT Processor Extensions

>A recent question on the Eclipse Web Tools Platform newsgroup asked how to make the XSL Tools editor in WTP 3.1 aware of custom extensions. One proposed solution is to use the XML Editor’s template support and add them. However, this makes those extension templates available all the time even when you may not necessarily need or want them.

Processors like Xalan and Saxon allow for additional extensions to be defined. The extensions allow for additional functionality that is not included in the base language. These extensions can be additional elements, or attributes. XSLT extensions are defined in their own namespace. The eclipse XSLT editor extends and enhances the existing XML editor, which itself is already namespace aware. So there are a couple of options for some simple built in support both of which require a grammar for the extensions.

  1. XML Catalog – One could add the grammar for the extensions to the WTP XML catalog.
  2. Create a Custom URI Resolver

Each of these will work, however, one may not necessarily want to do an XML Catalog contribution and there may be different versions of the grammar need to be used depending on if XSLT 1.0 or XSLT 2.0 is being used. To this end, we’ll take a look at how to use the Custom URI resolver method.

Implementing Xalan Redirect Extension:

Xalan has its own implementation to allow XSLT 1.0 to output multiple documents. Currently the eclipse XSLT editor does not know about this extension or the elements and attributes that go with it. WTP also has a little known extension point that allows adopters to contribute custom URI resolvers. The XML Catalog implementation is implemented as a custom URI resolver, and the determination of which XSLT grammar to load (i.e. XSLT 1.0 or XSLT 2.0) is also implemented using a custom URI resolver.

The Xalan extension provides three element extensions in the http://xml.apach.org/xalan/redirect namespace:

  1. open – opens a file
  2. write – writes to the file
  3. close – closes the file.

The XML Schema grammar for this may look like:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
<xsd:element name="write" type="WriteType">
<xsd:complexType name="WriteType">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:attribute name="file" type="xsd:string" use="optional"/>
<xsd:attribute name="append" type="xsd:string" use="optional"/>
<xsd:attribute name="select" type="xsd:string" use="optional"/>

<xsd:element name="open" type="OpenType"/>
<xsd:complexType name="OpenType">
<xsd:attribute name="file" type="xsd:string" use="optional"/>
<xsd:attribute name="append" type="xsd:string" use="optional"/>
<xsd:attribute name="select" type="xsd:string" use="optional"/>

<xsd:element name="close" type="CloseType"/>
<xsd:complexType name="CloseType">
<xsd:attribute name="file" type="xsd:string" use="optional"/>
<xsd:attribute name="select" type="xsd:string" use="optional"/>

This grammar will be used during the resolution of the redirect namespace. To implement this we need to have our plugin depend on the org.eclipse.wst.common.uriresolver plugin. We will make use of the extension point this plugin provides.


Here we are saying that when URIs need to be resolved, execute our RedirectResolverExtension class file, and have it try to resolve the uri that is passed.

package org.eclipse.wst.xsl.xalan.core.internal.resolver;

import java.net.URL;

import org.eclipse.core.resources.IFile;
import org.eclipse.wst.common.uriresolver.internal.provisional.URIResolverExtension;
import org.eclipse.wst.xsl.xalan.core.internal2.XalanCore;

* Redirection resolver implementation
public class RedirectResolverExtension implements URIResolverExtension
public String resolve(IFile file, String baseLocation, String publicId, String systemId) {
if (!XalanCore.XALAN_REDIRECT_NAMESPACE.equals(publicId)) {
return null;

URL pluginURL = XalanCore.getDefault().getBundle().getEntry("/schemas/redirect.xsd"); //$NON-NLS-1$
String xalanFileURL = pluginURL.toExternalForm();
return xalanFileURL;


The class looks for the Xalan Redirect namespace, and if it is found, then it will return the url to where the grammar can be found that defines the elements and attributes for the particular XSLT extension.

An XSLT as follows will make the XSLT editor aware of the grammar, and make it available for content assistance.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"

<xsl:template match="/">


So when the appropriate plugin is in place, you can get basic content assistance for your custom XSLT extension. The key to activating it is the xmlns:redirect=”http://xml.apache.org/xalan/redirect&#8221; declaration.

We are working on an extension point, hopefully for WTP 3.2M3, that will leverage this ability and provide even more specific functionality for some of the elements and attributes that can’t be expressed within the grammar itself. The extension implementation shown here is planned for WTP 3.2M3.

This entry was posted in eclipse, xml, xslt. Bookmark the permalink.

One Response to >XSLT Processor Extensions

  1. javieth says:

    >This whole information is absolutely useful and interesting. i like this blog because this blog is easily understandable, and that is invaluable to the readers. I wanted to buy viagra online, and i saw this blog. I think this information will be useful for me, because i want to know more about processors.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s