[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xalan-dev
Subject:    Re: Xalan and Mozilla
From:       Alan Gutierrez <ajglist () izzy ! net>
Date:       2003-01-07 2:34:08
[Download RAW message or body]

David N Bertoni/Cambridge/IBM wrote:

>
>
>Alan Gutierrez <ajglist@izzy.net> wrote:
>  
>
>>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.
>>    
>>
>
>This is pretty easy, although it can be really inefficient, as was noted in
>the dialog you posted from the Mozilla newgroup.
>
>  
>
>>2) Can Xalan take DOM as input?
>>    - Yes, unless I missed something.
>>    
>>
>
>We can take anything that can be wrapped in our interfaces.  The wrapper
>from the Xerces DOM to our "DOM" is just one example of that.
>
>  
>
>>3) Can Xalan produce DOM as output?
>>    - Yes, unless I missed something.
>>    
>>
>
>Yes, because producing "DOM" is just one instance of something listening to
>one of our event handlers on the output stage.
>
>  
>
>>4) Can Xalan's XPath be used outside of XSLT?
>>    - Yes, unless I missed something.
>>    
>>
>
>Yes.
>
>  
>
>>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.
>>    
>>
>
>This is much trickier.  There is some instrumentation in Xalan for
>implementing debuggers (ActiveState uses/used Xalan for one of their
>products).  Even more instrumentation could be added via conditional
>compilation.  I've been tempted to remove the small amount that's there in
>release builds, but haven't so far.
>
>However, halting and resuming execution is tricker, because we use the
>processor's stack to pass around some of the state of the execution.  We
>could change that, but I suspect that would impose serious performance
>problems.
>
>Hope this help.  Feel free to post more questions.
>
>Dave
>  
>


[prev in list] [next in list] [prev in thread] [next in thread]