[Forwarding this to the list, because I seem to have edited the To line
wrong.]
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
Saxonica
On 3 Oct 2017, at 13:57, Rowan Collins <rowan.coll...@gmail.com> wrote:
On 3 October 2017 10:04:57 BST, O'Neil Delpratt <on...@saxonica.com> 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.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
