I've been talking with people working Mozilla's XSLT capability about integerating Xalan with Mozilla. As a user of Open Source software I'd like develop for a single implementation of XSLT. It seems both Apache and Mozilla would benefit from a pooling of efforts.
Here are the questions we pertaining to integration along with the answers I've gleaned from the Xalan documenation and code. 1) Would it be difficult to make Xalan C++ work with an implmentation of the DOM other than Xerces C++? - Not particularly. 2) Can Xalan take DOM as input? - Yes, unless I missed something. 3) Can Xalan produce DOM as output? - Yes, unless I missed something. 4) Can Xalan's XPath be used outside of XSLT? - Yes, unless I missed something. 5) Can Xalan halt and resume exection? - Er, I think? I need ask more questions about this on both sides. Any help you might provide would be greatly appreciated. Alan Gutierrez Below is a dialog from netscape.public.mozilla.xml. ------------------------------------------------------------------------------ Jonas Sicking wrote: > Alan Gutierrez wrote: > > I am interested in boosting the perforamance of XSLT in Mozilla. > > Currently, Mozilla uses Transformiix to do XSLT transformations. It seems > > that it would be possible to bridge the Mozilla DOM to Xalan-C++, and have > > Xalan-C++ manipulate that DOM for both the XSLT documents and the input > > and output XML documents. > > To see if this is possible we need answer to the following questions: > > 1. What does it use as input-soure-document > 2. What does it use as input-XSLT > 3. How does it generate its output > 4. Does it fullfill other requirements that mozilla has: > a) ability to parse and execute XPath expressions outside > of XSLT > > and in a not-too-far-future we want > > b) ability to halt an exectution halfway through and resume > it again. > 1. > After very quick look at the xalan-website it looks like they use > something very similar to a DOM. It should be possible to write wrappers > so that each xalan-node wrapps a mozilla-node. This is exactly what we > do now, so we would be no worse off then we are now. > > However this is not a very good solution, since you have to do a > hash-lookup every time you navigate through the DOM, to get from the > mozilla-node to the wrapper-object. This is costly and something that we > want to get rid of. > > We are planning to change transformiix to work with a walker object > instead of working with node-objects. Would such a rewrite be possible > in Xalan? Would the xalan-group accept such a change? > > 2. > I have no idea what xalan does here. Does it work on a DOM, or do they > compile the stylesheet into some other object? > > If they compile it into another object it must be possible to take a > mozilla DOM and compile it into such an object. > > 3. > Again, i've only very breifly looked at Xalan, but it seems like they > create the result through an interface that has functions like > startElement(), endElement() and characters(). If this is the case it > should be fairly simple to write an implementation of that interface > that creates a mozilla DOM. I am going to post a copy of this message on their mailing list, with a follow post asking about creating a wrapper for the mozilla DOM. It seems that Xalan is DOM agnostic. They appear to have a set of bridge classes. > 4. > a) > This is usually not a hard requirement, so I wouldn't expect this to > cause much trouble. Doesn't loook that way, no, if we can use the Mozilla DOM. http://xml.apache.org/xalan-c/usagepatterns.html#xpath > b) > This could be a very big problem. Transformiix requiered pretty much a > rewrite of the XSLT code to fullfill this requirement (this work is > underway). Would it be possible to do in xalan? Would the xalan-group > accept such a change? ?? Is this what you are talking about ?? If not it seems like a good start. http://xml.apache.org/xalan-c/usagepatterns.html#incremental > We need to get in contact with someone on the xalan-team to get sure > answers. > > / Jonas Sicking As I said. I am going to post this and a DOM wrapper question over on the [EMAIL PROTECTED], that is why I didn't snip context. I've got an Apache module (Perl) that I am moving to Xerces/Xalan C++ this week to get myself familiar with the API. Alan Gutierrez
