Kelly Graus wrote:
Thank you for the response. I apologize for posting in the incorrect list.
I am using the C++ processor, not Java. And yes, I meant
XSLTInputSource - it was the end of a very long day!
I was just using std::stringstream as a first attempt to get it
working. I will implement something more efficient once I figure out
the rest of the problems (I was thinking of deriving a class from
istream, unless you have any better suggestions).
Deriving from istream is one way to do it, but that's a pretty complicated
endeavor. Take a look at the sample applications, and you'll find there
are several easier and probably more efficient ways to do it.
I'm having a small problem with the EntityResolver class. I have
created a custom EntityResolver, and called the setEntityResolver
function on the XalanTransformer. Then I create an XSLTInputSource
object with a std::stringstream containing the first xslt document
(again, just until I implement a custom stream that directly interfaces
with our stream classes). Then I call compileStylesheet on the
XalanTransformer, which causes my EntityResolver to be called. However,
the systemId that is passed in has the current working directory
prepended to it (the publicId is NULL).
Is this the correct behavior? It seems like it should be the job of my
EntityResolver to do any resolving if necessary. Am I just using it
incorrectly?
Yes, that's correct behavior. The parser is provided the fully-resolved
system ID of the entity it's looking for.
Dave
