Re: [xsl] Optimizing Trax

["Mark R. Diggory" <mdiggory@xxxxxxxxxxxxxxxxx>]

> At 09:26 AM 6/24/2003, you wrote:
>
> > It provides an a couple utilities over SAX and DOM that allow you to 
> > only build DOM fragments for the subtrees of the Document you'll 
> > actually be transforming against. It currently has a simple facility 
> > that reads the XSLT template for matches and keys to build a list of 
> > elements, it then passes matched sax events onto a DOMBuilder to 
> > build a DOM fragment, this DOM fragment can then can be transformed 
> > against using the same XSLT.
>
>
> The problem with this approach in the general case is that there are 
> many occasions when there is an expectation for a node to match a 
> built-in template: the absence of a template to match a given node is 
> not sufficient warrant for removing that node.
>
> It sounds like a pretty cool idea for situations where this is checked 
> against, however. (If I understand correctly.)
>
> Cheers,
> Wendell
Yes, 100% correct, its still a custom approach where you have to know 
alot about the structure of the xml content and in the end the templates 
have to be very "fragment" specific because the ancestor path 
information above the DOM is not available from within the Transform. So 
all tranformational rules need to be local to the fragment your working 
in. But, this really good for things like efficient 
editing/adding/removing nodes from a SAX stream via XSLT. I have an idea 
to grab something like JXPath and make it process a limited set of XPath 
functionality in establishing the rules for which SAX Events to DOM.

-Mark

--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu



XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list