Xiaocun,
At 09:53 AM 6/18/2003, you wrote:
I see. Looks like my options are:
1. investigate forward-walk
2. enhance incoming data (the current design is to
keep process prior to XSLT generic with no business
logic, this will have to break that)
Splitting the process in two could achieve this goal without having to
break your design principle all the way back. It should be able to pipeline
your transforms through Saxon using your copy of WebLogic, or even batch
process them. (Are there performance constraints?)
In fact, I'd propose that if you're trying to encapsulate your "business
logic" in XSLT, that eventually you'll be wanting to pipeline in any case.
(Although I should add that a nodeset() function or its equivalent -- the
application of processing result node sets that we'll be getting in XSLT 2
-- can be used to emulate a pipeline.)
3. go back to Saxon6.0.2. Somehow variable was
allowed in xsl:key match/use in that version, I had to
expand the variable out when I upgraded to Saxon6.5.2,
which is the cause of this problem I am having now.
When the variables are expanded out, the performance
went down drastically concurrently, which is another
reason I might decide to go back.
4. wait until WebLogic6.1 supports JDK1.4 and move up
to Saxon7.5.1 (this probably will never happen)
Since we might want to skip WebLogic7.1, we seems
committed to WebLogic6.1 for an extended period,
therefore option #3 might be the most viable at this
time for me.
I wouldn't give up on the others. It's a pity to lock yourself into a
non-conformant version of a tool just for one "feature". :->
Could we please see your data again, with a concise restatement of the
problem and perhaps desired output? (Sorry.)
Cheers,
Wendell
___&&__&_&___&_&__&&&__&_&__&__&&____&&_&___&__&_&&_____&__&__&&_____&_&&_
"Thus I make my own use of the telegraph, without consulting
the directors, like the sparrows, which I perceive use it
extensively for a perch." -- Thoreau
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list