Hi, Martin. Martin von Gagern <martin.vgag...@gmx.net> wrote on 11/13/2009 11:42:07 AM: > Adam Jenkins wrote: > > I would really like to revive it > > Me, too. > > See http://thread.gmane.org/gmane.text.xml.xalan.devel/17653 > and http://thread.gmane.org/gmane.text.xml.xalan.devel/17705 > and maybe also https://code.launchpad.net/xalan > > > and I have some spare development band width to put towards it, > > I can't make any promises, but I'm willing to contribute some time as > well. Already have, writing a bunch of patches. > > What has me worried is infrastructure. As long as we are not granted > enough access to svn and jira, we won't be able to efficiently use > Apache infrastructure. And as the people around here at least aren't > giving such permissions to anyone dropping by, at least not on a short > timescale, I assume that this will hinder development. > > So my idea is, we might consider moving this development elsewhere. One > possibility would be launchpad, where I've already published an svn > import as well as a branch with some fixes included. Another possibility > might be openjdk, where a copy of xalan forms the basis of the xslt > processor shipped with openjdk, using mercurial as the underlying > revision control system. Or we might prod people around here a bit > harder, to gain the access we require to contribute efficiently.
I'm sorry that I haven't been able to contribute to the project over the past year. My other work really hasn't permitted me the time. Coincidentally, I was just getting myself set up to spend some time reviewing some of your patches as I'd promised. If those look good, I wouldn't see any impediment to nominating you for committer status. For whatever it's worth, I think it would be most beneficial for the Xalan-J community if development of the processor continued within this venue. This is the place people are used to going to for questions about Xalan-J and XSLTC, and for help. > If I were to write an xslt processor from scratch, I'd either drop DTM > altogether, or have the transformation work on some interface which can > be provided from both DOM and DTM. I'd also try to get some closer > integration between the xslt interpreter and the xsltc compiler, i.e. > have a bunch of classes, each with methods compile() and interpret(), so > people could more easily ensure they perform the same operations. Certainly that would be better architecturally. The current state of the code reflects the fact that XSLTC and the Xalan-J interpreter were initially developed independent of one another. Some Xalan committers spent quite a lot of time getting them to share more functionally equivalent components. At one point, XSLTC had its own independent implementation of the XPath data model that was similar to DTM. We spent quite a bit of time adapting it to share DTM with the interpreter. It also had its own independent serializer implementation. We spent a lot of time merging those implementations. Overall, I think those changes benefited both processors, in that bugs found by a user of one processor could be fixed for both; performance improvements in DTM or serialization that were targeted to XSLTC could benefit both processors. One weakness of XSLTC is in its error checking. It's nowhere near as thorough as the Xalan-J interpreter in that respect. That's something that could be remedied by having them share their abstract syntax tree representations - common classes with compile() and interpret() methods as you suggest. One other thought - keeping Xalan-J development here, there's a greater potential for cross-pollination of ideas with Xalan-C. For example, if I recall correctly, Xalan-C does its interpretation of a stylesheet in an iterative fashion rather than a recursive fashion. That allows it to process stylesheets that have a much deeper recursive run-time stack than the Xalan-J interpreter. Keeping Xalan-J here makes it easier to share those kinds of ideas. Thanks, Henry ------------------------------------------------------------------ Henry Zongaro XML Transformation & Query Development IBM Canada Lab T/L 313-6044; Phone +1 905 413-6044 mailto:zong...@ca.ibm.com
