How do I tell Cocoon to stop adding carriage-returns during XSL
The short answer is that this is not a Cocoon issue. You need to
read up on XSLT usage. Please see
other resources for XSLT,
specifically, the XSL FAQ and discussion lists.
The long answer is that you need to use the XSLT function
normalize-space() whenever you want to rely on the content
of an xml element.
your HTML output, then you might mistakenly try to use the following
construct in your XSL stylesheet:
which will produce:
The line-endings in the content of your "
Note that there are many more issues about whitespace handling. Please
refer to the relevant XSLT resources rather than clutter up the Cocoon
Is (your description here) kind of functionality appropriate for a stylesheet?
When this kind of question arises, ask yourself:
Am I using my stylesheet to address style concerns, or am I programming with it?
Could I solve this problem once and for all during Generation?
Isn't my problem better solved with a Transformer, since it requires coding?
There is not one, nor only one, answer. In Cocoon, you can accomplish the same thing in a number of different ways. Nonetheless, if your transformation depends on something specific happening during generation, it will be more difficult to reuse your code.
Here's a hint. Do all that you possibly can in a Generator. Add only what is absolutely
necessary with Transformers. Use stylesheets to change format or style,
not to code. This approach will make your system more manageable and reusable because it removes dependencies between components.
Can I use the same XSLT processor and still specify different processing options for different
For example, I found that PDF processing is faster with Xalan when I turn incremental processing off.
Yes. For Cocoon version 2.0.3, check out the following Cocoon snippet.
Can I use different XSLT processors when processing different pipelines?
Yes. For Cocoon version 2.0.3, adapt the approach discussed in the following Cocoon snippet.
How can I remove namespaces from my xml files?
Sometimes adding xsl:exclude-result-prefixes attributes
to the <xsl:stylesheet> or literal result element is not effective
in removing all namespace declarations. For example, namespace nodes copied
from the source document within <xsl:copy> or <xsl:copy-of> instructions
(commonly found in catch-all stylesheet templates) will not be excluded.
There are two approaches to this problem.
One approach is to add a transformation step in your pipeline (or adjust your final stylesheet) with the following:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<!-- remove element prefix (if any) -->
<!-- process attributes -->
<!-- remove attribute prefix (if any) -->
Another approach is to extend your serializer component, described here.
What's "wrong" with use of the document() function in Cocoon?
Using the document() function for aggregation in Cocoon may break
Separation of Concerns (SoC). That is, the designers of Cocoon
view inclusion and transformation as different functions, best
handled by separate Cocoon components. Treating them
separately allows you to achieve performance gains and increases
the resusability of your pipelines.
Alternatives to the document() in the Cocoon environment include
aggregation or the use of a multi-stage transformation using the
XInclude Transformer. This involves transforming a list of documents
(generated dynamically or statically) by adding xinclude elements which
reference (via xpointer) specific document content, and then transforming
again via the XInclude Transformer, to obtain the desired result. For an example of this, see this email.
You'll achieve better performance if you aggregate content prior to transformation.
This allows you to take full advantage of Cocoon's pipeline caching. In contrast,
making dynamic document() calls inside an XSLT within a cached pipeline is problematic.
At this time, Cocoon does not recognize changes in documents (called by the document() function)
until the requested page expires from cache.
Understand that the document() function was designed *before* xinclude
with xpointer facilities existed. Had such capabilities been available,
perhaps the document() function, which essentially mimics xinclude and xpointer,
would have never been added to XSLT.
Please note that if you must work with your XML files outside of the
Cocoon environment, you may need to use the document() function
in order to utilize the limited capabilities of other pipeline engines.
This includes engines which are not xinclude-capable or which
lack a predefined way to indicate document processing steps. If you
are working with legacy code from non-pipelined engines, you may need to use
the document() function as well, at least initially.
If you do use the document() function in Cocoon, you can still observe SoC by
having separate XSLT stylesheets perform inclusion and transformation functions.
For example, you can put multiple XSLT transforms in a pipeline and have the
first one perform inclusion and the second one perform transformation. However,
be mindful of some unresolved caching issues in Cocoon related to the document() function.
At this time, Cocoon is unable to check validity of content included via the document()
function. In addition, the document() function implemented by Xalan is inefficient. See:
Until this bug is fixed, consider using Saxon instead for document() function-related parsing
For other aggregation/inclusion approaches, please stay tuned for XpathDirectoryGenerator (2.1 scratchpad),
as well as Forrest's Libre (currently alpha in the Forrest cvs).
How can I add my FAQ to this document?
Follow the instructions found in How-To Author an FAQ.
How can I suggest improvements to existing FAQs?
Given the rapid pace of change with Cocoon, many individual FAQs quickly become out-of-date and confusing to new users. If you have the relevant knowledge, please consider updating other FAQs on this page for technical errors. If you see a few typos, please consider fixing them too. Follow the instructions found in How-To Author an FAQ.