You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Mark Weaver <ma...@npsl.co.uk> on 2006/04/17 23:20:03 UTC
[Fwd: Xalan-C: dynamic nodesets from XPath functions]
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 <ma...@npsl.co.uk>
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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: [Fwd: Xalan-C: dynamic nodesets from XPath functions]
Posted by Mark Weaver <ma...@npsl.co.uk>.
> Hey Mark,
>
> Sorry, I've been incredibly busy with work these days, so I haven't had
> lots of time to look at possible patches.
>
A pain isn't it! I guess you haven't had chance to take a look yet?
> Is there any chance you could adapt the exslt-regexp patch to work with
> Xerces-C's regular expression implementation? That would be far better
> than requiring boost, since Xerces-C is guaranteed to be there. Another
> choice would be to support both, with a fallback to Xerces-C if boost is
> not available, or not desired.
It would be possible. It seems that they are probably not the same, but
I doubt it matters too much (AFAICS exslt is extremely loosely
specified, and the basic syntax of the regular expressions is the same,
so it's going to make most people happy I would have thought).
>
>>
>> >
>>> 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.
>>>
>
> dyn and random are trickier, and random is still under-specified (there
> was some discussion on the EXSLT list about this at least 3 years ago).
> I'd like to make sure the implementation is clean, but is also
> flexible. Hopefully, I can find some time in the next 3 weeks to look
> at the patches.
>
dyn seemed ok to me. Were you thinking of anything specific?
random roughly follows an implementation of EXSLT for .NET (can't
remember where that was exactly). I couldn't find another one.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: [Fwd: Xalan-C: dynamic nodesets from XPath functions]
Posted by David Bertoni <db...@apache.org>.
Mark Weaver wrote:
> Any interest in this? I've also finished off:
>
> regexp: http://www.blushingpenguin.com/mark/xalanc/exslt-regexp.patch
> (requires boost)
>
> date: http://www.blushingpenguin.com/mark/xalanc/exslt-dates.patch
> (everything except the date-format extension element).
>
> Would be nice to get some feedback, even if it's just to be a bit more
> patient ;)
>
> Thanks,
>
> Mark
Hey Mark,
Sorry, I've been incredibly busy with work these days, so I haven't had
lots of time to look at possible patches.
Is there any chance you could adapt the exslt-regexp patch to work with
Xerces-C's regular expression implementation? That would be far better
than requiring boost, since Xerces-C is guaranteed to be there. Another
choice would be to support both, with a fallback to Xerces-C if boost is
not available, or not desired.
>
> >
>> 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.
>>
dyn and random are trickier, and random is still under-specified (there
was some discussion on the EXSLT list about this at least 3 years ago).
I'd like to make sure the implementation is clean, but is also
flexible. Hopefully, I can find some time in the next 3 weeks to look
at the patches.
Thanks!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: [Fwd: Xalan-C: dynamic nodesets from XPath functions]
Posted by Mark Weaver <ma...@npsl.co.uk>.
Any interest in this? I've also finished off:
regexp: http://www.blushingpenguin.com/mark/xalanc/exslt-regexp.patch
(requires boost)
date: http://www.blushingpenguin.com/mark/xalanc/exslt-dates.patch
(everything except the date-format extension element).
Would be nice to get some feedback, even if it's just to be a bit more
patient ;)
Thanks,
Mark
>
> 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 <ma...@npsl.co.uk>
> 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: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org