citeproc-js and JavaScript engines Was: Disambiguation: changes to test fixtures

CSL Development
1

To return briefly to the issue of executing citeproc-js using embedded JavaScript engines. In the meantime I am able to use citeproc-js embedded into Ruby using either Rhino (for JRuby) or SpiderMonkey (for Ruby 1.8.7); because the V8 is so fast it would be great to use that to run citeproc-js, too; however, the engine itself comes without the DOM parsing functions (such as getElementsByTagName) – could anyone suggest a good DOM parsing solution for citeproc-js + V8? (Perhaps ‘jsdom’?)

Many thanks!

Sylvester

2

If you’re planning to parse a style and then use it many times, jsdom would work. It’s what we use in citeproc-node (https://www.zotero.org/svn/citeproc-node/trunk/). However, jsdom is glacially slow, at least with larger documents. If you can’t cache and reuse styles, it’s possible that SpiderMonkey would be faster than V8+jsdom.

Simon

3

Have you checked on the state of alternative XML libraries lately Simon?

I see this mentioned a fair bit, for example:

https://github.com/polotek/libxmljs/wiki

Like o3 (which is now on npm) it has some dependencies though (but
libxml is notoriously fast):

http://stackoverflow.com/questions/5931099/alternatives-to-libxmljs

Still hoping we can get to “npm install citeproc” at some point.

Bruce

4

The idea was to use it for the cite processor test suite to simultaneously test citeproc-js, citeproc-hs and citeproc-ruby, i.e. I would mostly use very short styles but caching is more or less out of the question. My results with SpiderMonkey are very encouraging so I will probably stick with it.

Many thanks,

Sylvester

5

o3 crashes and leaks memory, which makes it unsuitable for use in a production environment. My understanding is that libxmljs is the only working DOM parser. Unfortunately, the DOM it exposes isn’t W3C-compliant, so it was unsuitable for my uses when I was testing it. citeproc-js would need a new XML parsing module to support libxmljs’s non-standard API, but it could probably be made to work. However, it may not simple to adapt a node.js binary package to run in Ruby.

SpiderNode (https://github.com/zpao/spidernode), which is node.js ported to use SpiderMonkey instead of V8, presumably has E4X support. However, I’ve been hearing rumblings that, at some point, Mozilla will be rewrite a large part of their E4X implementation in pure JS and remove features that can’t be implemented with an ES5 Harmony proxy.

Simon