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