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 ;)
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
