This seemed to have got lost (at least, I haven't seen it appear on the
list in about 24 hours -- I apologise if this is duplicated).
In the meantime, I've also implemented the rest of exsl:dyn & exsl:random.
Dyn:
http://www.blushingpenguin.com/mark/xalanc/exslt-dyn.patch
Random:
http://www.blushingpenguin.com/mark/xalanc/exslt-random.patch
random:random-sequence doesn't seem very well defined (returns number+,
which presumably means nodeset). I attempted to follow the only other
implementation I could find -- that of the EXSL.NET implementation.
Since Jira seems to be working again I'll open bugs for the bugs
mentioned below.
Mark
-------- Original Message --------
Subject: Xalan-C: dynamic nodesets from XPath functions
Date: Mon, 17 Apr 2006 01:42:13 +0100
From: Mark Weaver <[EMAIL PROTECTED]>
To: xalan-dev@xml.apache.org
I'd like to bring this up yet again :) I've been using various patches
to support this since Xalan-C 1.3, and I've recently updated them to
1.10, plus (in theory) made them work properly.
Patches are all here:
http://www.blushingpenguin.com/mark/xalanc/
to avoid the mail being bounced for size; I will attach to mails/jira
tickets if desired.
The first patch:
http://www.blushingpenguin.com/mark/xalanc/dynamic-builder.patch
exposes XalanDocumentBuilder from XPathExecutionContext.
This is the scaffolding for allowing extension functions to create
nodes. In summary, it adds createDocumentBuilder/destroyDocumentBuilder
to all of the XPathExecutionContext derived classes. The rationale here
is that this essentially allows functions to do the same as
FunctionDocument() does. Thus, as far as I can tell, it should be ok.
My previous attempts had an XObject own the returned document, which was
not safe because nodes are treated as existing for the duration of a
query/transform in the rest of the framework. To support this
requirement, similarly to FunctionDocument() the lifetime of any created
documents is owned by the XPathExecutionContext (i.e. they exist until
reset() or the execution context is destroyed).
The second patch:
http://www.blushingpenguin.com/mark/xalanc/exslt-strings.patch
This only works after the first patch!
This adds the rest of the EXSLT string functions (str:replace(),
str:tokenize(), str:split()). I think these are mostly correct,
although str:replace() is a little underspecified; I attempted to
conform to the sample implementation. These may well be useful, and
hopefully provide a bit more incentive to apply the first patch.
I have tested these patches against the 1.10 release, and they also
apply cleanly to the current SVN trunk. (I have not yet been able to
compile this however due to lack of the correct xerces version; but I
don't forsee see major problems there).
http://www.blushingpenguin.com/mark/xalanc/external-function.patch
possibly applies, the stylesheet portion at least provides some rough
tests of the functionality of the new string functions (thus, this
relies on the previous two patches).
Thanks,
Mark
P.S. Some other things in my patch pile which likely are best treated
separately are listed below, but may be of interest. I will attempt to
address these separately at a later date, but in the meantime any
comments are welcome.
http://www.blushingpenguin.com/mark/xalanc/xml-entity-resolver.patch
Exposes XMLEntityResolver from Xalan as well as EntityResolver. Useful
for me as I either need to figure out and implement EntityResolver2
(plus then expose that), or use this (apparently) ready made interface.
For me, EntityResolver is not useful because I need to be able to
resolve relative references correctly.
http://www.blushingpenguin.com/mark/xalanc/function-pairs-leak.patch
Fixes a leak in XalanTransformer when installExternalFunction is used.
http://www.blushingpenguin.com/mark/xalanc/function-pairs-past-end.patch
Fixes a possible overrun of the functionPairs array
http://www.blushingpenguin.com/mark/xalanc/multiple-init.patch
Fixes an issue calling XalanTransformer::initialise() multiple times
(which happens frequently for me when loading multiple DLLs that use
Xalan; it's "thread safe" in the sense that it is called from DllMain()
which on Windows is protected by a thread lock).
http://www.blushingpenguin.com/mark/xalanc/no-u_cleanup.patch
Prevents calling u_cleanup(). ICU3.4 causes crashes if you call
u_cleanup() multiple times.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
