This is a practical issue relating to proposed Xalan-J bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=30197
Consider this stylesheet:
<?xml version="1.0"?> <xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<!-- test a stylesheet that use
method="text" -->
<xsl:output method="text"/>
<xsl:template match="/">
<element1>12345</element1>
<element2>67890</element2>
<element3/>
<element4>0987654321</element4>
<xsl:comment>test</xsl:comment>
<xsl:processing-instruction name="test">PIs are not treated
as literals in
XSLT?</xsl:processing-instruction>
</xsl:template>
</xsl:stylesheet>
Suppose we transform a DOM Document, XOM document, SAX InputSource or
some other such representation of an XML document. Furthermore
suppose that instead of serializing the output as a stream or a
string we create another DOM document, XOM document, etc. Should the
xsl:output element have any effect?
My claim is that it should not. Anything said in the xsl:output
element applies only when the document is serialized to a an actual
XML document represented as a sequence of characters or bytes, not
before. This is what earlier versions of Xalan did. Faced with this
case, they would produce a result tree containing six child nodes of
different kinds,
element, comment, and processing instructions.
However, in the last few versions, Xalan produces a single text node
containing all the element content. The elements, comments, and
processing instructions should be reduced to plain text only when the
document is serialized, not before. In my opinion, Xalan appears to
be jumping the gun when the output method is text and incorrectly
assuming that it can generate a single text node. However, at least
on of the Xalan developers disagrees with me, and thinks this is
acceptable and indeed desirable behavior.
What does everyone else think? I've always assumed xsl:output only
applied in serialization, not result tree construction but Joe
Kesselman thinks the spec language is at best ambiguous on this
point. Interpretations from working group members would be
particularly helpful.
One thing that worries me is that if this is made optional (because
xsl:output is support clearly optional according to the spec) then
this becomes yet another point where different implementations behave
differently with no clear way for client code to figure out what's
likely to happen.
--
Elliotte Rusty Harold
elharo(_at_)metalab(_dot_)unc(_dot_)edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA