Re: [xsl] Generating XML fragment to DOM node using XSL

Subject: Re: [xsl] Generating XML fragment to DOM node using XSL
From: Steve Dussinger <sdussing@xxxxxxxxx>
Date: Tue, 16 Dec 2003 15:37:04 -0800
On 12/16/03 3:08 PM, "cknell@xxxxxxxxxx" <cknell@xxxxxxxxxx> wrote:

> XSLT transforms one tree of nodes into another. That means that it doesn't do
> anything to the original document, ever. If you want to change the original
> document, you must serialize the output to file system, giving the new
> document the same name and path as the original.
> 
> It seems to me that what you are really after is DOM programming. You want to
> get a set of nodes from one document and append them to some element in a
> second document. For DOM programming, you may want to look at:
> http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/java-binding.html
> and
> http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html

I'm not trying to change the source document. I'm trying to place
transformed data under an existing node in the destination tree. It seems to
me that XSL should be able to create a DocumentFragment in some way, such
that I can place the children directly into a destination DOM tree at the
location I choose.

If I look at the documentation for Xalan, that seems to be what they imply,
if you use a DOMResult object to hold the result of the transformation. The
documentation for the DOMResult constructor in Xalan states:

"Use a DOM node to create a new output target. In practice, the node should
be a Document node, aDocumentFragment node, or a Element node. In other
words, a node that accepts children."

When I read this, it seemed to me that any element node could be used as a
location into which my transformed data could be placed. This is exactly
what I want, since I already have a document which needs this transformed
data. I don't want to have to take the existing, preparsed destination tree,
convert it back to text, and then reparse it after I've done  the
transformation.

As for doing this with the DOM, that won't really work for me. I need to be
able to supply the end user with a mechanism by which he can convert data
formats into the internal forms required by this tool. I certainly can't
expect the end user to write DOM traversal code to do this and then somehow
install that code into my tool suite...

Thanx,
    Steve



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread