Re: Xalan Java XPath parser design

Mukul Gandhi <[email protected]> Mon, 18 May 2026 11:50:57 +0530
Newsgroups gmane.text.xml.xalan.devel
Message-ID <CABuuzNNJdQRDq4UbsUFDbzmU=STKW2P7ebtt1pLcL1OANSkkEQ@mail.gmail.com>
Hi Joseph,
    I've added the discussed Xalan Java OpMap component design
information within the page,
https://xalan.apache.org/xalan-j/design/design2_0_0.html (within XPath
Module section).

On Mon, May 18, 2026 at 12:17=E2=80=AFAM Joseph Kesselman via dev
<[email protected]> wrote:
>
> Good analysis, Mukul, though perhaps a bit kinder to us than we deserve. =
Probably worth adding to our official documentation.
>
> The xpath and XSLT intermediate representation was originally designed fo=
r interpretive Xalan. One of the reasons it is so compact is that PCs were =
much smaller and slower at the time so storage and access efficiency was cr=
ucial. (The same reason DTM its designed essentially at the byte level for =
compactness.) But compactness can also buy performance advantages; it's as =
close to C or ASM data models as Java let us get.
>
> When Sun donated their xslt compiler to Apache, the IBM / Apache team adj=
usted it to share this representation so it could be integrated with Xalan.=
 I don't recall how much the Xalan front end had to change to support that;=
 not a great deal, I think.
>
> There could certainly be better choices. I've mentioned some of them in p=
ast discussion of IBM Research's Xylem processor.


--=20
Regards,
Mukul Gandhi