XSLT adding your own functions

[Duane Morin]

Is this normal use of XSLT? At the top of our XSL file we have:

<xsl:stylesheet ...
xmlns:nl="http://www.jclark.com/xt/java/com.company.package.ProcessXML">
....

Then within the XSL itself we call:

<xsl:value-of select="nl:generate-url('x', 'y', 'z')" />

Where generate-url is actually defined in ProcessXML.java:

public static String generateUrl (String x, String y, String z) {
...
}

This works just fine when I'm performing the XSL transformation within
my own Java app that has access to the ProcessXML class. However, it
completely ruins my ability to use an XSL editor or do any type of
external transformation which aborts with an exception about not being
able to find the generate-url function.

So my question, since I didn't write this code :), is this standard
procedure for extending XSL to do what you want? If so, is there
something that I'm missing which would enable a standalone XSL
transformation engine (such as might be found in an IDE) to recognize
the functions I added? Is there a way that I could write some sort of
stub/dummy plugin for generateUrl that would do nothing, but at least
keep the transform from failing?

This approach has served us fine in a world where the Java guys also
did all the XSL coding and so always worked within the scope of a Java
app, but we're getting to a point where we'll have dedicated content
people and I'd like them to be able to use an XSL editor of their
choice. Right now the only option is "Edit XSL, check in to source
control, request a rebuild (since they cannot build the product on
their workstations), look at results, repeat."

Thanks!

[Duane Morin]

Ok, with a little extra reading let me followup my own question with
some more intelligent ones. Now that I discovered that this trick
is called an "extension function" it was much easier to find info :).

* Is the way we're doing it specific to JClark's parser, such that
switching over to another one might still break me even if I was doing
everything else right?

* Where exactly do I *put* my extension functions so that the XSLT
parser can find them? That's the part I can't seem to locate.
Obviously they are not at www.jclark.com. They're not at any
http resolvable location, actually - but I dont think they have
to be. When the class in question exists in the same jar as the
app doing a transform, then it works fine.

Hope those are better questions :). Thanks!

Duane

In article <55**************************@posting.google.com >,
Duane Morin <dm****@morinfamily.com> wrote:

Is this normal use of XSLT? At the top of our XSL file we have:

<xsl:stylesheet ...
xmlns:nl="http://www.jclark.com/xt/java/com.company.package.ProcessXML">
...

Then within the XSL itself we call:

<xsl:value-of select="nl:generate-url('x', 'y', 'z')" />

Where generate-url is actually defined in ProcessXML.java:

public static String generateUrl (String x, String y, String z) {
...
}

This works just fine when I'm performing the XSL transformation within
my own Java app that has access to the ProcessXML class. However, it
completely ruins my ability to use an XSL editor or do any type of
external transformation which aborts with an exception about not being
able to find the generate-url function.

So my question, since I didn't write this code :), is this standard
procedure for extending XSL to do what you want? If so, is there
something that I'm missing which would enable a standalone XSL
transformation engine (such as might be found in an IDE) to recognize
the functions I added? Is there a way that I could write some sort of
stub/dummy plugin for generateUrl that would do nothing, but at least
keep the transform from failing?

This approach has served us fine in a world where the Java guys also
did all the XSL coding and so always worked within the scope of a Java
app, but we're getting to a point where we'll have dedicated content
people and I'd like them to be able to use an XSL editor of their
choice. Right now the only option is "Edit XSL, check in to source
control, request a rebuild (since they cannot build the product on
their workstations), look at results, repeat."

Thanks!

[Patrick TJ McPhee]

In article <yv8Ub.177920$nt4.776706@attbi_s51>,
Duane Morin <dm****@morinfamily.com> wrote:

% * Is the way we're doing it specific to JClark's parser, such that
% switching over to another one might still break me even if I was doing
% everything else right?

It seems like it. As a rule, if you need to use extension functions,
I suggest using the ones from http://exslt.org where applicable,
since they're the most widely supported. What gets supported and how
to add new extensions is completely dependent on the xslt processor
you're using, though.

You can use the function-available() to test for the availability of
an extension function

<xsl:choose>
<xsl:when test='function-available("nl:generate-url")'>
<xsl:value-of select="nl:generate-url('x', 'y', 'z')" />
</xsl:when>
<xsl:otherwise>
** url made up of x, y, and z **
</xsl:otherwise>
</xsl:choose>

--

Patrick TJ McPhee
East York Canada
pt**@interlog.com

[Duane Morin]

pt**@interlog.com (Patrick TJ McPhee) wrote in message news:<bv**********@news.eusc.inter.net>...

You can use the function-available() to test for the availability of
an extension function

Awesome - that's exactly what I needed! Thanks!!

Duane