Theoretically, it ought to be possible to wrap a SAXSource around a SAXResult, which would avoid the need to build a DTM model. The problem is, SAXResult does not implement the XMLReader API, and the sequence of API calls is a bit different.
You could, I suppose, create an XMLReader wrapper around the whole TrAX API. I haven't seen it done, but offhand I can't think of anything that would prevent it from working. Might be a useful thing to have on hand. (Or we could consider enhancing InputSource to accept a Transformer as well as an XMLReader, but I think that's a lower-priority wishlist item.)
The way we've tended to solve this sort of problem in the past has been to handle the additional processing in Xalan extensions rather than in the entity resolver (http://xml.apache.org/xalan-j/extensionslib.html#pipedocument). That may not handle your usage pattern.
Another solution, of course, is to restructure the problem -- bring the entity in normally via document(), but do so within a context that allows your stylesheet to either preprocess it into the desired form (styling it into a variable, then using the nodeset extension to access that variable as a tree) or just interpret its original form rather than preprocessing it.
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"may'ron DaroQbe'chugh vaj bIrIQbej" ("Put down the squeezebox and nobody gets hurt.")
- result to a source Andrew Welch
- Re: result to a source Simon Kitching
- Re: result to a source Foxy Shadis
- Re: result to a source Simon Kitching
- Joseph Kesselman
