> I thought it is a saxon specific problem because it works
> using Xalan2.
There's a history to this.
XSLT 1.0 as originally published says:
"It is an error for output escaping to be disabled for a text node that is
used for something other than a text node in the result tree. "
Note this concept of "the result tree" - XSLT 1.0 is based very much on the
idea that there is a single result tree. Many vendors, not all, interpreted
this to mean that it was an error to use d-o-e when writing a text node to a
result tree fragment.
Erratum E2, however changed this, and stated explicitly that you could use
d-o-e when writing to a variable containing a result tree fragment. This was
known in the WG as the "sticky d-o-e" debate: specifically, d-o-e is
effectively a boolean attribute attached to each character in a result tree
fragment, which stays with it when the fragment is copied.
This change caused a lot of grief when it came to defining XSLT 2.0, which
abolished result tree fragments and turned them into fully-functional
temporary trees. To preserve the stickiness of d-o-e, it would have been
necessary to explicitly add this bit-per-character to the data model and
explain how it was propagated through the wide range of operations that were
now permitted on nodes in temporary trees.
In 2.0, d-o-e is deprecated, and processors are not required to implement it
at all. Using d-o-e when writing to a variable is covered by this sentence:
"If output escaping is disabled for an xsl:value-of or xsl:text instruction
evaluated when temporary output state is in effect, the request to disable
output escaping is ignored."
(Temporary output state is in force when evaluating variables or functions
and in other similar situations).
This is specifically listed as a known incompatibility: clause 20 of J.1.4
"An erratum to XSLT 1.0 specified what has become known as "sticky
disable-output-escaping": specifically, that it should be possible to use
disable-output-escaping when writing a node to a temporary tree, and that
this information would be retained for use when the same node was later
copied to a final result tree and serialized. XSLT 2.0 no longer specifies
this behavior (though it permits it, at the discretion of the
(But I think the final phrase in parentheses is incorrect: it does not
permit it. Section 20.2 takes priority, because it is normative, whereas
Appendix J is non-normative.)