Hi Joseph,
There were few discussions in the past (the latest XalanJ dev
thought process, as per Gary), where Gary suggested that, we should
make a next XalanJ XSLT 1.0/XPath 1.0 release based on what is
currently pending on XalanJ jira. IMHO, if you want, you may look
through which XalanJ issues on Jira since 2.7.2 release need
work/finalization and have us commit those improvements to XalanJ
repos for next release.
I feel, another task you may .look is help XalanJ implement XSLT 3.0 &
XPath 3.1.
I had previously developed a fairly good skeleton of XPath 3.1 parser
(available at,
https://s3.us-east-2.amazonaws.com/org.apache.xalan.xpath.v31/xpath_parser_dev.zip).
If you could, review this XPath 3.1 parser and identify what needs to
be done to complete it to be usable within an XSLT 3.0 processor (we
now need, an XPath 3.1 evaluator for this XPath parser). I'm ready to
complete implementation of its evaluator further, based on your
feedback, or if you wish you may pick up writing XPath 3.1 evaluator
for this XPath parser.
Another development path, to implement an XPath 3.1 processor for
XalanJ is extending an XPath 2.0 processor available at
https://github.com/xercesj/xpath20 (that's used by XercesJ).
Please advise us further, on these topics, if you're motivated to do
these activities.
On Wed, Feb 2, 2022 at 10:37 PM Joseph Kesselman <kesh...@alum.mit.edu> wrote:
>
> Or has everyone moved to other tools?
>
> As kesh...@watson.ibm.com, I was involved in Xalan's development. (And
> Xerxes, to a _much_ lesser extent; I wrote their first DOM implementation.)
>
> I retired last year, which means I have some hours available. I have a
> personal project under way right now, but after I get version 1.0 of that
> published I could be persuaded to re-familiarize myself with the Xalan-J code
> and do some cleanup and improvement on it. Some of the ideas we were playing
> with internally were patented, but (a) I think IBM would grant approval to
> Apache if we ask nicely, and (b) I think the one I'd want to use first may
> have elapsed by now in any case.
>
> Note that I'm not volunteering to tackle the current implementation of
> Xalan-C. That was based on Xalan 1.0, which is a somewhat different
> architecture, I wasn't involved in the translation, and C++ is not my strong
> suit; I was able to keep Xalan-C limping along for a while, but I would
> recommend rewriting it completely, preferably _after_ at least some of the
> work on Xalan-J has been done. (A shift to a cursor-based data model API in
> particular.) Also, I suspect that Xalan-C's code is horribly archaic at this
> point; C++ was still trying to find it's feet at the time it was written.
>
> Anyway, there it is: if there's significant demand, I can try to make myself
> available; if there isn't, I'd rather put my effort into something that would
> be more valuable to the community.
--
Regards,
Mukul Gandhi
