October 3, 2017 20:firstname.lastname@example.org (Rowan Collins)
[Forwarding this to the list, because I seem to have edited the To line
On 03/10/2017 14:58, Michael Kay wrote:
> I'm not 100% sure of my facts here, but I assume there is a significant call overhead every time there's a function call from the PHP world to Saxon's Java world or vice versa, which is acceptable if you're invoking a large operation such as an XSLT transformation, but which would be prohibitive for the fine-grained calls found in the DOM API, such as getParent() and getValue(). So having Saxon provide a DOM interface to a PHP application, or having Saxon navigate a DOM created on the PHP side of the fence, both look like they could be very expensive: that's why our current API only operates at the level of unparsed lexical XML. If there's a solution to that problem, or if you think it's a non-problem, I would love to know!
> Michael Kay
>> On 3 Oct 2017, at 13:57, Rowan Collins email@example.com> wrote:
>> On 3 October 2017 10:04:57 BST, O'Neil Delpratt <firstname.lastname@example.org> wrote:
>>> The XSLT processor currently provided in the PHP core,
>>> however, only supports the XSLT 1.0 standard published in 1999.
>> In case anyone is not clear, the current XML functionality provided in PHP core is all built on the libxml2 library which originated in the GNOME project, and its accompanying libxslt library: http://xmlsoft.org/
>> Is there any possibility for Saxon to be implemented as a replacement for more of these components in the future, or is it likely to always be used with its own functions?
>> I've personally never used or wanted to use XSLT, but have used XPath with the SimpleXML and DOM extensions, so would be interested in any way of extending that beyond XPath 1.0.
>> Rowan Collins