Bug #4506


Poor serialization of XML-format xsl:message output

Added by Michael Kay over 2 years ago. Updated over 2 years ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


When xsl:message output contains non-trivial XML (e.g. elements with namespaces) it is not properly serialized. For example, redundant namespace declarations are not eliminated.

Raised by Vladimir Nestorovsky at

Actions #1

Updated by Michael Kay over 2 years ago

The logic implementing this xsl:message instruction is surprisingly contorted.

xsl:message evaluates its select attribute and/or sequence constructor in pull mode, that is by calling iterate(), and then sends the returned items to the target Receiver using the append(item) method.

Because in this case the content of xsl:message is an instruction that likes to be evaluated in push mode, the instruction constructs a tree and then returns its root element node. The message receiver's append() method then decomposes this tree back to a sequence of events that are sent to the message receiver. Since the message receiver is essentially a raw XmlEmitter, there's no logic on this pipeline to eliminate redundant namespace events.

I would think it's almost certainly more straightforward for xsl:message to evaluate its operand in push mode (using the process method) to avoid building the intermediate tree.

But the central problem, I think, is that the events should be pushed to the message emitter via a NamespaceDifferencer, which would handle the namespace deduplication.

Actions #2

Updated by Michael Kay over 2 years ago

  • Status changed from New to Resolved
  • Fix Committed on Branch 10 added

Resolved. I have made two changes:

(a) the default MessageFactory used by the XsltController now puts a NamespaceDifferencer in the message output pipeline before the MessageEmitter; this has the effect of eliminating redundant namespace declarations.

(b) the xsl:message instruction now evaluates the message operand in push mode (Expression.process()) rather than pull mode (Expression.iterate()). This is not strictly necessary to fix this bug, but it makes the execution path for xsl:message a lot simpler.

Actions #3

Updated by O'Neil Delpratt over 2 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.1 added

Bug fix committed in the Saxon 10.1 maintenance release.

Actions #4

Updated by O'Neil Delpratt over 2 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF