« Robots take over Science! | Main | More Short Reviews »

Tuesday, January 06, 2009


Feed You can follow this conversation by subscribing to the comment feed for this post.

Ivan Pepelnjak

The arithmetic and string function support in XSLT 1.0 is so basic that I have problems implementing obvious things, let alone MD. XSLT 2.0 might be different, but I will not touch it until it gets significant browser-side support.

If you're using Saxon, it should not be too hard to implement an extension in Java.


@ivan: thanks for the comment. i don't care so much about browser support. for anything a little bit more complicated XSLT 2.0, and in particular XPath 2.0, is such a big advantage over the 1.0 versions that i am really preferring the new versions. and i am doing server-side programming anyway.

but i don't want to start developing code that depends on a particular XSLT implementation. and i am not even sure there is an EXSLT for XSLT 2.0 for community consensus around extension functions. but even if there was one, i'd prefer to have an XSLT implementation of MD5, so that code could run on any XSLT processor.

C. M. Sperberg-Mcqueen

Erik, in your search for MD5 implementations in XSLT, you may have missed the Java-based extension function defined by Norm Walsh and mentioned at http://norman.walsh.name/2005/projects/xslflickr

Or does your desire for multi-implementation support make you averse to extension functions implemented in Java?

On the heap space question; I have not tested systematically, but I believe other implementations are also subject to out-of-memory errors.

Since I found your post in a search for MD5 implementations in XSLT as part of some work on simple authentication in Cocoon, I'd be interested in your space-intensive functions. (I'm willing to say that passwords won't be arbitrarily long.)


@michael: thanks for the pointer, i had not seen that before. it's good to know there is such a thing, but i guess i was mostly curious how you would best implement a low-level bit-oriented algorithm such as MD5 in XSLT, so the java implementation is not all that interesting in that regard.

i never looked deeper into my heap space issues (i just assigned more memory to the JVM), but i guess if you're careful in your implementation, and use an XSLT processor that supports tail recursion (saxon does it, no idea about others), then heap space problems might not be such an issue anymore.

The comments to this entry are closed.