Re: [xsl] Is it OK for xsl:output to affect the construction of an unserialized result tree?

Subject: Re: [xsl] Is it OK for xsl:output to affect the construction of an unserialized result tree?
From: david_n_bertoni@xxxxxxxxxx
Date: Tue, 20 Jul 2004 09:11:27 -0700
> 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?

You are already talking about things which are outside the scope of the
XSLT 1.0 recommendation, so I don't see how you can apply it.

> 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.

Yes, but the XSLT 1.0 recommendation does not provide any access to the
result tree, nor does it allow access to the structure of a result tree
fragment, so how can you even know what the result tree looks like without
using processor-specific extensions, or APIs?  In fact, there is nothing in
the XSLT 1.0 recommendation that requires that a processor actually create
the result tree, and Xalan-J does not.

On the other hand, I do think it's problematic (and a bit of a stretch),
not to represent the result tree properly in this case, since it makes
stylesheets less flexible, and breaks backward-compatibility.  Perhaps if
you override the output method through TrAX, you can work around the


Current Thread