For generic questions about XSL stylesheets and transformations, use the
XSL-List -- Open Forum on XSL hosted by Mulberry Technologies. There is an archive that can be searched as well. Please
review the archive before posting a new question.
For specific questions on Xalan-C++, see firstname.lastname@example.org and email@example.com on
http://archive.covalent.net/. To subscribe to these mailing lists, see
Mailing Lists. Again, please review the archives before posting a new
What is Xerces-C++ and why do I need it?
Xerces-C++ is a validating XML parser written in a portable subset of C++. Xerces-C++ makes it easy to give your application the ability
to read and write XML data. Like Xalan-C++, Xerces-C++ is available from the Apache XML site:
Which version of Xerces should I be using?
The Xalan-C++ release notes includes information about the Xerces-C++ release with which the Xalan-C++ release has been coordinated
and tested. See Status
Should I be using the Xerces DOM or Xalan DOM?
The Xalan DOM implementation is highly optimised for transformations. However, whilst you can build documents in the Xalan DOM,
subsequent modification will not work. The Xalan DOM is designed to be either an input or an output from a transformation, not
as a general DOM implementation.
So in cases where you want to simply transform documents using Xalan, using the internal DOM implementation is the best approach.
In cases where you want to modify the DOM document on the fly, you should use the Xerces DOM as the base document. You can wrap
the Xerces DOM in a wrapper (see passing in a Xerces DOM)
to then use as an input to a Xalan transformation. Alternatively you can output the result of a transformation to a Xerces DOM
document (see working with DOM input and output). In either case, the Xerces document
can be freely modified. However, after you modify the document, you need to re-build the wrapper so that any changes are replicated
in the Xalan wrappers.
I have encountered problem executing the Xalan-C++ sample applications after rebuilding them under Win32 Environment (Windows NT 4.0, SP3).
When I tried to execute the sample, I receive the error message
"Debug Assertion Failed! ... Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)".
You may be mixing debug and release versions of executables and libraries. In other words, if you are compiling the sample for debug,
then you should link with the debug version of the Xalan-C++ and Xerces-C++ libraries and run with the debug version of the dynamic link
You must also make sure your application is linking with the Debug multithreaded DLL run-time library or the Multithreaded DLL
run-time library. To check this setting do the following in Visual C++:
Select Settings from the Project menu.
Click the C/C++ tab.
In the Category drop-down list, select Code Generation.
In the Use run-time library drop-down list, select Multithreaded DLL for the Win32 Release configuration, or select Debug
Multithreaded DLL for the Win32 Debug configuration.
Once you have changed this setting, you must rebuild your project.
What do I need to rebuild Xalan-C++ on Windows?
In order to build Xalan-C++ on Windows, you will need the supported version of Xerces-C++ and MS Visual C++ 6.0 installed with Service
Pack 5 for Visual C++ and Visual Studio. In previous versions of Xalan-C++, the requirement on MS Visual C++ 6.0 was to have Service
Pack 3 installed. In this case, you should also apply the bug fixes for the C++ standard library that shipped with Visual C++ 6.0.
These fixes are available from the Dinkumware site:
If you do not want to apply the Dinkumware patches, or you are using a different Service Pack, you must rebuild all of the Xerces
and Xalan binaries.
To build Xalan-C++ on supported UNIX platforms, you need Xerces-C++, the GNU make utility, and a supported C++ compiler. For more
details see: Steps for doing a UNIX build.
I get errors in the Makefile when running the make utility. What's wrong?
You must use the GNU make utility. Other make utilities may not work with the Xalan Makefile
What is ICU and why do I need it?
The International Components for Unicode(ICU) is a C and C++ library that provides robust and full-featured Unicode support on
a wide variety of platforms. Xalan-C++ uses the ICU to extend support for encoding, number formatting, and sorting.
I am getting a tar checksum error on Solaris. What's the problem?
The Solaris tar utility you are using does not properly handle files with long pathnames. You must use GNU tar (gtar), which
handles arbitrarily long pathnames and is freely available on every platform on which Xalan-C++ is supported. If you don't already
have GNU tar installed on your system, you can obtain it from the Free Software Foundation
http://www.gnu.org/software/tar/tar.html. For additional background
information on this problem, see the online manual
GNU tar and POSIX tar for the utility.
Is it possible to run Xalan-C++ from an Apache server?
A simple Apache module called ApacheModuleXSLT is provided as a sample.
It demonstrates how to integrate Xalan-C++ with Apache.
Is Xalan-C++ thread-safe?
Instances of XalanTransformer are not thread-safe; each thread should use its own instance.
In order to support very efficient use in multi-threaded applications, Xalan-C++ is designed to avoid synchronization as much as
possible. Each thread of execution is required to have its own set of "support" objects that contain the state of the
transformation. Accordingly, no synchronization is required when multiple threads are executing.
Parsed ("compiled") stylesheets (see Compiling stylesheets) and parsed
source documents may be freely shared by multiple threads of execution without worrying about providing synchronized access to
them. The only exception to this rule: You use XercesParserLiaison to parse a document after calling
XercesParserLiaison::setBuildBridgeNodes(false) or XercesParserLiaison::setThreadSafe(false). In this case, the document
cannot be shared by multiple threads of execution. For reasons of performance, we do not recommend the use of
XercesParserLiaison, so this should not be an issue for most applications.
All other objects in Xalan-C++ are not thread-safe. Each thread must have its own instance of each object.
See the ThreadSafe sample program for more information.
What can I do to speed up transformations?
To maximize performance, here are some suggestions for you to keep in mind as you set up your applications:
Use a compiled stylesheet when you expect to use the stylesheet more than once.
Set up your stylesheets to function efficiently.
Don't use "//" (descendant axes) patterns near the root of a large document.
Use xsl:key elements and the key() function as an efficient way to retrieve node sets.
Where possible, use pattern matching rather than xsl:if or xsl:when statements.
xsl:for-each is fast because it does not require pattern matching.
Keep in mind that xsl:sort prevents incremental processing.
When you create variables, <xsl:variable name="fooElem" select="foo"/> is usually faster than
Be careful using the last() function.
The use of index predicates within match patterns can be expensive.
Can I validate an XSL stylesheet?
An XSL stylesheet is an XML document, so it can have a DOCTYPE and be subject to validation, but you probably will have
to write a custom DTD for the purpose.
The XSLT Recommendation includes a DTD Fragment
for XSL Stylesheets with some indications of what you need to do to create a complete DTD for a given
stylesheet. Keep in mind that stylesheets can include literal result elements and produce output that is not valid
You can use the xsl:stylesheet doctype defined in xsl-html40s.dtd for stylesheets that generate HTML.
What does the XalanDOMException HIERARCHY_REQUEST_ERR mean?
It means that an attempt was made to add a node to a DOM that would create an invalid structure. For example, text nodes
are not allowed as children of the document node.
This is a common error when attempting to transform to DOM. Source documents and stylesheets that might produce valid serialized XML
might not produce value DOM. The usual suspect is text nodes being generated before the document element is generated.
If you think you have seen this error because of a bug in Xalan-C++'s source tree implementation, please post a bug report on Bugzilla, and attach a minimal source document
and stylesheet that produce the problem to the bug report.
How do I output a transformation to a DOM, a file, an in-memory buffer, or as input to another transformation? Since the C++
language can automatically construct an XSLTResultTarget from any of its constructor's argument types, you usually don't need
to create one explicitly.
The output parameter of XalanTransformer::transform() is an XSLTResultTarget which has many constructors.
Output to a file:
The easiest way is to use a null-terminated string containing the file name to create an XSLTResultTarget. Or, use an
instance of std::ofstream. The command line executables, and many of the sample applications use file names, so take a
look through the source code for more information.
Output to an in-memory buffer:
Use an instance of std::ostrstream or std::ostringstream to create an XSLTResultTarget. See the StreamTransform sample
for more information.
Input to another transformation:
Any of the previous output targets could be used as the input to another transformation, but the FormatterToSourceTree
is probably the best for efficiency reasons. See the source code for the TestXSLT command line program for more
Why won't XSLTInputSource work with std::istrstream on Sun Solaris using Forte/Sun Workshop compiler?
There is a bug in Sun's C++ standard library implementation; see
this bug. The short answer is that you need to
get a patch. The bug report includes the code for a simple program which you can use to see if your environment has the bug.
There is also a link to the patch.
My transformation outputs to a XalanDocument (actually XalanSourceTreeDocument underneath) but W3C DOM functions like
DOMElement::setAttribute don't work! Am I going crazy or what?
No, you aren't going crazy. Xalan's default source tree is read-only for efficiency. If you need a DOM that supports
modifications, use the Xerces DOM instead. See the TransformToXercesDOM sample for more information.
XalanTransformer outputs errors to the console. How do I, for example, output error to a file?
By default, XalanTransformer creates a XalanTransformerProblemListener (a subclass of ProblemListener) that writes
output to std::cerr. To change this you can:
Redirect std::cerr from the command line.
Call XalanTranformer::setWarningStream with a different std::ostream before calling XalanTransformer::transform.
Instantiate your own XalanTransformerProblemListener with a different output stream and call
XalanTransformer::setProblemListener() before calling XalanTransformer::transform().
Subclass some ProblemListener type and do custom handling of errors (you still then need to tell XalanTransformer
instances to use your ProblemListener.)
In most case you probably want to do one of the first two.
How do I programmatically get the file name, line number, and column number for an error in an XML file?
Create a custom ErrorHandler (a Xerces-C++ class) and call XalanTransformer::setErrorHandler before parsing any sources.
How do I make a char* out of XalanDOMString (or vice-versa)?
See the static method XalanDOMString::transcode, or the functions TranscodeToLocalCodePage in the API documentation.
However, you should be very careful when transcoding Unicode characters to the local code page, because not all Unicode
characters can be represented.
Is there a table of error codes somewhere? How about a summary of what methods throw which exceptions?
There isn't, but we're working on it.
The Xalan extension functions (xalan:node-set, etc.) don't work for me. Help!
Did you declare the namespace on the xsl:stylesheet or xsl:transform element? It should look like this:
<xsl:stylesheet version="1.0" xmlns:xalan="http://xml.apache.org/xalan"> ...rest of stylesheet
If you did and you still have problems, you might want to ask the mailing list.
Why can't I ouput my results to a file on Windows 95/98?
Well, you can, but it doesn't always work. Neither Windows 95 or 98 are supported or tested. There have been reports of
problems on it, especially regarding Unicode support. See
this post and
Why does Xalan emit a warning when using the XSLT function format-number()?
There is no Apache Perl wrapper, however Edwin Pratomo has written a wrapper for Xalan-C++ version 1.4 that can be found
Why can't I find the LocalMsgIndex.hpp file?
The LocalMsgIndex.hpp file is not shipped with the distributions because this file is generated during compile time. This
file is created at the start of the build process and customized for the locale and message set you are using.
On Windows, the LocalMsgIndex.hpp header is generated by the Localization project. By building any project that has a
dependency on the Localization project, will trigger the Message Localization component to built and the LocalMsgIndex.hpp
to be generated.