diff --git a/docs/source/advancedDevelopment/muchData/muchData.rst b/docs/source/advancedDevelopment/muchData/muchData.rst
index 553d5939..443501ad 100644
--- a/docs/source/advancedDevelopment/muchData/muchData.rst
+++ b/docs/source/advancedDevelopment/muchData/muchData.rst
@@ -22,4 +22,4 @@ Files stored on disk are stored in ``${java.io.tmpdir}/${instance.name}/temp-mes
 
 The Frank!Framework in general `streams` messages flowing through a pipeline. This means that the Frank!Framework only holds in memory the bytes it is currently working with, not entire messages. This helps the Frank!Framework to process large messages without getting out of memory, but there is a caveat. The caveat is related to XSLT processing. When XSLT version 2.0 or version 3.0 is being applied (attribute ``xsltVersion=2`` or ``xsltVersion=3``), then XSLT processor Saxon is used. This XSLT processor does not support streaming. This means that if some message is transformed using an XSLT transformation and if XSLT version 2.0 or 3.0 is used for this, then the entire message has to be stored in memory. This can cause an out of memory exception for large messages.
 
-This issue can be fixed by using `xsltVersion=1`. In that case, XSLT processor Xalan is used. Xalan does implement streaming and hence large messages can be processed without memory issues. The price to pay is that XSLT 1.0 is less feature-rich than version 2.0 and version 3.0, making it harder to code the intended XSLT transformation. Most XSLT processing senders and pipes use Saxon by default. The exception is the ``ForEachChildElementPipe``. That pipe uses Xalan by default. This exception has been made by WeAreFrank! because the ``ForEachChildElementPipe`` is meant to iterate over large messages.
+This issue can be fixed by using ``xsltVersion=1``. In that case, XSLT processor Xalan is used. Xalan does implement streaming and hence large messages can be processed without memory issues. The price to pay is that XSLT 1.0 is less feature-rich than version 2.0 and version 3.0, making it harder to code the intended XSLT transformation. Most XSLT processing senders and pipes use Saxon by default. The exception is the ``ForEachChildElementPipe``. That pipe uses Xalan by default. This exception has been made by WeAreFrank! because the ``ForEachChildElementPipe`` is meant to iterate over large messages.