This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Using DOM with XSLT/XPATH (might be dangerous ?)


> I just found some code which I think might be quite dangerous.
> assume the following transformation stylesheet:
>
>  <xsl:transform>
>>     ...
>>     <xsl:variable name="foo" value="java:invoke(@method)"/>
>>     <xsl:variable name="foo2"select="$foo\'xpath expression'"/>
>>     ...
>  </xsl:transform>>
>
> Here a method of a java object is invoked which returns an DOM
> object. In the second variable assignment a 'xpath expression' is
> applied to the the result (a dom tree). Well I was told that it works
> but my personal view is that this is quite dangerous, for the following 
> reasons:
>
> a) It is assumed that the XSLT processor understands the DOM
>     returned by the invoked java method.
> b) It is assumed that the internal realization of the XPath is DOM 
>     based.
> 

I'm not sure why you think there is any dependency on the DOM?  The function
is going to have to build the nods in the correct document in order for them
to be recognized. As long as it uses JAXP interfaces to do so you don't
really care what the underlying implementation is.  You know that since the
processor supports extensions it is going to understand the results you
return to at least some extent.  Now as long as you return objects that are
cast according to the documented casting rules for your processor (which
should be based on the standards) you can also reliably manipulate the
results in the XSLT in accordance to the expected casting rules.  A Nodeset
or RTF coming back from the function will be cast correctly to a nodeset
within the document.  The biggest issue you might have is that it is really
cast to a RTF and not a nodeset.  I use the same coding pattern all the
time, with the difference that I always explicitly convert the results back
to a nodeset (using whatever processor specific extension). Eg:

	<xsl:variable name="foo"
select="x:nodeset(java:myclass.mymethod(parameters))"/>
	<xsl:apply-templates select=".">
      	<xsl:with-param name="foo" select="$foo/data/*"/>
	      <xsl:with-param name="default"
select="$foo/auth/*[1]/@default"/>
   	</xsl:apply-templates>

In this case I'm using Xalan 2.3.1, which doesn't actually build a DOM that
one would normally recognize (though it provides DOM like interfaces). At
home I have similar code that uses Saxon...

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]