IBM followed Xalan with an XSLT3 optimizing compiler, which was almost a complete rewrite. Unfortunately, it was only released as part of Websphere, and was not donated to Apache. (I think it's released name was xthpc or something like that, XSL Transformation for High Performance Computing; the internal name was Xylem.)
And we had another major step forward in progress when we were summarily pulled off that effort. Internal politics, headcount raids between departments, disagreement about how we were going to position our new acquisition of DataPower. And the new management had no interest in donating it to Apache. .. so, yeah, most of the world never heard about it and had no access to it, and it basically got dropped on the floor and forgotten. And there are few of us who even remember it. Obviously I'm still a bit grumpy about that... I'm not sure how much of that work was patented or if IBM would give Apache a free license to those. One conclusion drawn from that effort: The non-deterministic behavior of JIT compilers make performance optimization extremely difficult. Simple run-to-run variation swamped some of the measurements we were trying to make. It's a lot easier to optimize in a J9 system or similar, where the JVM behavior is more predictable. -- /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/ () Plaintext Ribbon Campaign /\ Stamp out HTML mail! ________________________________ From: Mukul Gandhi <muk...@apache.org> Sent: Tuesday, September 12, 2023 10:35:43 AM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: Re: xalanj new release proposal Hi Joseph, On Tue, Sep 12, 2023 at 7:11 PM Joseph Kesselman <kesh...@alum.mit.edu> wrote: > When IBM implemented 3.0 we started with the API and data model work needed > to migrate Xalan to the XSLT3 data model rather than from the "what could be > back-ported to 2.0" angle I believe, IBM had produced an XSLT 2.0 processor and not 3.0. Please correct me if I'm wrong. I still do have IBM's XSLT 2.0 implementation binaries with me, having got them from a team member from IBM's XSLT 2.0 team, within the year 2012 I guess. I did work with IBM till 2015 for few years and I've enjoyed those years of my work :) > In addition to new utilities and schema data types, 3.0 changes some > semantics, specifically in removing the distinction between node sets and > temporary trees (which has always been a bit > frustrating). It isn't clear whether we could get away with that one and > still claim 2.0 conformance; negative tests which detect the difference would > fail. Have you been avoiding that (eg > building automatic conversion into your new functions), or are you working to > the 2.0 definitions? Are you referring to XPath 3.1 (data) type promotion (ref, https://www.w3.org/TR/xpath-31/#id-type-promotion-and-operator-mapping), required during evaluations of few XPath operators and for function calls? This has been implemented to a great extent, on XalanJ dev branch repos xalan-j_xslt3.0. > (My own highest architectural priority would be getting us into cursors > rather than DTM iterators, which would give us a path toward 3.0 semantics > and make running over data other than DTM > much simpler... but I'm biased; the cursor cutover was my baby, all those > years ago. And it's not a small change.) Currently, on XalanJ dev repos branch xalan-j_xslt3.0, I'm handling a sequence of XDM items using two data structures together (XNodeSet and ResultSequence). The XalanJ's XSLT 3.0 implementation may be achieved in a simpler way, if we had a single data structure to work with for XDM sequence. I think, we cannot discard XalanJ's XNodeSet, since lot of XalanJ functionality is already using that. And we need to have something else as well, to handle an XDM heterogeneous sequence (having ResultSequence class, helps us achieve that). -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
