Hi Adam, 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. > Having spent quite a bit of time code diving through Xalan, I also > think it's a pretty good product and pretty good code base...and i > missing something?? My impression is that the whole DTM thing has quite a number of drawbacks. It doesn't interact nicely with garbage collection, imposes pretty tight restrictions on the number of documents and nodes that can be processed, and also imposes some limitations on the interaction with DOM-based extension functions, e.g. with respect to the context of returned DOM nodes, their parents in particular. 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. But on the whole, I believe Xalan is quite a good basis, so I'd rather improve on it than start from scratch. > Is Xalan worth resurrecting and continueing on with? I'd say yes. I hope it can be done. Greetings, Martin von Gagern
signature.asc
Description: OpenPGP digital signature
