well that patch (jaxen 31) should be "considered harmful". Once I dug into it I found there were nasty problems with what I had done, whenever you really need all the elements. There's a bunch of stuff that held me back from doing something better... - I experimented with trying to use jaxen under a tiger-a-like api[1]; the saxpath and navigator bits are fine, but I couldn't square the rest of it up without breaking things. (BTW did I mention that Navigator.getXPath() is evil? it prevents reuse of navigators with a different xpath api...) - there's better xpath algorithms that could be used instead of just making jaxen fail-fast; but these would pretty much require api changes. - the automated builds for the release never got going, so I lost a bit of motivation... - and of course theres lotsa non-jaxen stuff to do...

... however when I last looked, I think the only way to get my patch to work would be to go back to jaxen as it is now and replace all the Lists with implementations that are lazy. Which seemed like a pile of work.

I'm curious about a couple of the results: substring('12345', -42, 1 div 0) (jaxen fails)

Is this the release version of jaxen? I think the one in cvs does this correctly (I seem to remember fixing it). Ho hum, I'll have to check.

Also, there's no mention of what object model was used with jaxen? I notice there are preceding:: tests in there which I think jaxen only does right on the DOM navigator?

-Baz

[1] I'm not sure how much I like that api - you can't register functions in the default namespace, and its missing ones like current(). But it's a standard - a blessing and a curse.

On Mon, 15 Nov 2004 13:17:24 -0500, peter royal <pete...@pobox.com> wrote: