result to a source 2003-04-10 - By Joseph Kesselman
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.")
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.)</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif"><br>
______________________________________<br>
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
<br>
"may'ron DaroQbe'chugh vaj bIrIQbej" ("Put down the
squeezebox and nobody gets hurt.")<br>
</font>
|
|
