xslt 2.0 and Ruby on OS X


I am attempting to parse an XML document against an XSLT 2.0 sheet. However, I am being told that the libraries on OSX 10.5.x only support XSLT 1.0 operations. When I look at xsltproc, I get this:

hmasing$ xsltproc --version Using libxml 20616, libxslt 10112 and libexslt 810 xsltproc was compiled against libxml 20616, libxslt 10112 and libexslt 810 libxslt 10112 was compiled against libxml 20616 libexslt 810 was compiled against libxml 20616

Does anyone have a concise guide to installing XSLT 2.0, the ruby xslt gems to work against those libs, and some good fu to pass my way? Please assume I am a total idiot in any instructions. Any help is greatly appreciated!

  • Hans


Sadly, Saxon is the only game in town with a free XSLT 2.0 implementation. Saxon itself is brilliant, but it is Java or .NET only, with all that that implies.

Invoking it from the command line or via a system call will incur a JVM startup cost every time, so you probably don't want to do that.

Some things you can try:

1) Are you sure you need XSLT 2.0? Unless you're using functionality that isn't in 1.0, your XSLT might be 1.0-compatible. Then you could use xsltproc. If what you need is in EXSLT, xsltproc has some support for that.

2) If you definitely need 2.0, then you'll want to create some sort of wrapper for saxon. A lot depends on what environment you want to use this in, so this might be a web service or something like that. For a project I work on, we use a little TCP listener program that wraps saxon. You can see it here: http://idp.atlantides.org/svn/idp/idp.contenttool/trunk/epiduke_saxon/ It works well for command-line batch transforms, and is very fast.

By : hcayless

It might be best to aggregate the data from all of your tables into a search index. Lucene is a free search engine, similar to how Google's search engine works (inverted index), and it should allow you to search by any of those values or any combination of them with relative ease.


Lucene comes with its own query language (again, very similar to Google's or any other Internet search sites syntax). The only drawback of using something like Lucene is you would need to build its index. You wouldn't be querying your database directly (which could get very complicated...inverted index are pretty much designed for what your trying to do), so you need to periodically gather up new information from your database and add it to your index. It might also be necessary to rebuild your index to remove unneeded data.

With Lucene, you get a pretty flexible query syntax that most people are familiar with (because pretty much everyone searches the internet), it performs very well, and is not terribly complicated. By using Lucene, you avoid the hit of using regular expressions (which are not the most performant text searching mechanism), and you don't have to write your own parser. Should be a win-win, aside from a little learning curve to build a Lucene index generator and figure out how to query that index.

By : jrista

I'd have the data in one database. If the data got to big or I knew it would be huge, I'd assign an id to each business, address etc, then have other tables which reference this data.

Regular Expressions would only be necessary if the user could define what they want to search for:

business: Argos

But then what happens if they want an Argos in Manchester (Sorry, I'm English), maybe then get the location of the user based on their IP but what happens if they say:

business: Argos Scotland

Now you don't know if the company has two words, or if there is a location next to it. All of this has to be taken into consideration.

P.s Sorry if that made no sense.

This video can help you solving your question :)
By: admin