Thanks again for the reply, your insight helped me understand the problem better. I think my biggest mistake was that I am parsing the SS with a DOMSource so I was thinking that the XPath evaluation would resolve to a node in the original stylesheet. I was hoping to pull the data from the underlying document and not the DTM version. This works when the XPath is operating on the XML document but you evaluate a param/variable in the SS, the original relationship to the DOM is lost. So in my extension element, I need to create a new output formatter because I need DOMResult and not a StreamResult.I need to do this because I need to take the result and import it into an existing DOM Document. Either that or I just punt, and pull in the data from the docuemnt() command.
My extension elements are pushing the envelope a bit. What I am
doing is creating an XSL dialect that allows you to describe a
Rich Client Editor that will edit XML files. Similar to XForms,
but down a bit of a different path because I needed to support
rich client functionality. The XSL Transformation produces a
Java object that is a SWT (Eclipse) based editor. The editor form elements are bound to the XML input document and is edited in
place as the form is edited, below are some screen shots. The
functionality I was going for is the ability to define a "New Record"
in the XSL so that the XML block can be injected into the Source
document based on a form action, i.e. a button click. It works,
I just loose the whitespace.
Thanks again John G
Here is a screen shot http://www.rapidxsl.com/xfe/FormView.jpg
The XSL that describes the editor http://www.rapidxsl.com/xfe/EditAppXML.xsl
The Source document http://www.rapidxsl.com/xfe/app.xml
Joseph Kesselman wrote:
Unfortunately, I haven't attempted writing extension elements -- just functions -- and I've got my head so entangled in XSLTC revisions that I'm not sure I remember the details of how interpretive Xalan is handling either. So the following may be completely off base. But...
If your xsl:output specifies indentation, that will create whitespace where the serializer thinks it might be useful; this feature doesn't directly affect whether whitespace from the source is preserved. So I *think* you're going to lose the whitespace from your param value, unless you start playing with xml:space and xsl:preserve-space. I'd have to play with it to be sure.
If we presume for a moment that extension elements aren't doing anything blatently odd, Kay's book has a few tips on how to deal with whitespace that either appears or vanishes unexpectedly. I don't think he covers everything, so also check http://www.dpawson.co.uk/xsl/sect2/N8321.html, which in turn points to some related resources.
______________________________________ Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more. "The world changed profoundly and unpredictably the day Tim Berners Lee got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
