Excellent design practices and I'm not really a hacker, I only play one for this current employer.
The incoming XML is truly trivial and the fault occurs before the XSLT transformer runs the XSLT, so either the code I have written is flawed (most likely) or it has stumbled over a real Xalan XPath bug. No, we can't switch to pathan for schedule and feature reasons. On Thursday 16 June 2005 12:10 pm, Axel Weiß wrote: > Lonnie VanZandt wrote: > > No, I can't share those because they are highly proprietary. But, they > > are actually irrelevant to conceptual work to be done. Which I can > > discuss. > > > > I have distributed servers which pass XML strings as their messages. > > The servers are mostly stateless and transform an input XML into an > > output XML based on XSLT-scripted "business logic". > > > > The transformer is humming along fine. > > > > However, occassionally, a server needs to peek into an incoming XML > > request or an outgoing XML reply in order to do content-specific > > processing above and beyond what the XSLT can do (such as determining > > destinations and session management). > > > > So, rather than code up a mess of DOM traversal code, I need/want to > > ask an XPathEvaluator to evaluate some "peeks" into the source and > > output XML documents. > > > > Therefore, a string of XML arrives on a socket, I parse the XML into a > > XalanDocument, I (try to) peek into the request with XPathEvaluator, I > > get any state I need, I set XSLT stylesheet parameters, I let > > XalanTransformer do its transformation, I (try to) peek into reply > > with XPathEvaluator, I get any state I need, and I send off the reply > > XML to the proper socket. > > > > I have two wishes: > > > > 1. That XPath::executeMore not return a null nodeset() or, at least, > > that XPathEvaluator::selectNodeList not try to nodeset() on a > > *XObjectPtr which isn't actually a NodeRefList. > > > > 2. To have the XalanTransformer use its parseSource method to parse > > the input XML once for both the XPath query and then for the > > transform() method (rather than constructing a separate XalanDocument > > with the parserLiaison just for the XPath evaluator) and then use the > > XalanTransformer to parse the reply XML so that the post-transform > > XPath query can use that without having to construct a new > > XalanDocument for the output string. > > > > Makes sense? > > That sounds all reasonable to me. However, when I develop some complex > concepts (and the above is fairly complex ;), I usually try to break > down some simple examples that show 1. the principles and 2. the core > algorithms. I usually enforce this when I run into problems and want to > communicate and discuss some non-obvious solutions. > > If I got you right, the problem is located in the (non-) ability of xalan > to evaluate some XPath expression. Anything special with this > expression? Can you possibly simplify the context where you encounter > the problem, to a xml-file/xpath-expression pair that can reproduce the > erroneous behaviour (and that is not top-secret;)? > > I have not very much experience with xpath-magics, just enough to be able > to write the stylesheets I demand. I heard about that xerces has very > little xpath support, xalan a bit more. But - did you already try > pathan? Maybe it's worth a look... > > Cheers, > Axel > > (You need not CC me, 'cause I'm subscribed here ;) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
