RFC proposal: Provide support for XSLT 3.0, XPath 3.1, and XQuery 3.1

  100811
October 3, 2017 09:04 oneil@saxonica.com (O'Neil Delpratt)
Hi,

We are considering submitting an RFC along the following lines and welcome your comments:

** Provide support for XSLT 3.0, XPath 3.1, and XQuery 3.1 **

PHP is frequently used to create web services that process XML input and deliver HTML to web clients. Often this is done by invoking XSLT transformations. The XSLT processor currently provided in the PHP core, however, only supports the XSLT 1.0 standard published in 1999. XSLT has moved on significantly since then, with XSLT 2.0 in 2007 and XSLT 3.0 in 2017. The newer standards provide many productivity benefits: regular expressions, grouping, multiple output files, support for JSON, support for HTML5, independent compilation of modules, to name a few. By failing to support these, PHP is becoming a less attractive development platform for XML-centric applications.

XML has been superseded by JSON as the format of choice for simple configuration and data files, but XML remains of strategic significance for document-based processing and for the vast number of industry-standard data exchange formats defined by XML schemas. XSLT 3.0 allows XML and JSON data to be mixed and combined.

PHP users needing access to XSLT 2.0 or 3.0 processing typically use messy workarounds, such as sending transformation requests over HTTP to a Java-based server, or using Java bridge technologies. Recently a version of Saxon has been developed with a native PHP API, and the aim of this RFC is to move this implementation into the PHP Core. The existing XSLTProcessor will remain available and will continue to provide XSLT 1.0 only, so existing applications will not be disrupted.

Enhancing the existing XSLTProcessor is not an option: it has fallen too far behind for this to be viable.

The Saxon implementation of XSLT 3.0 is a recognized leader in this field. This proposal offers to include the open-source version of Saxon (Saxon-HE) in the PHP core. Saxon-HE includes support for the minimum conformance levels of XSLT 3.0, XPath 3.1, and XQuery 3.1 defined by the W3C specifications, as well as some optional features such as serialization support. It achieves 100% pass rates for the relevant W3C test suites. (It excludes schema-aware processing, higher-order functions, streaming, and some other advanced options). The same API can also be used to invoke the commercial versions of Saxon, which support additional functionality and performance.

Saxon-HE/C is already available for PHP 7 as a free-standing product. Apart from the PHP interface, the source code is Java, and the product is built for the PHP platform using the (non-open-source) Excelsior JET compiler. Excelsior have a licensing scheme enabling the compiler to be used by open source projects (see: https://www.excelsiorjet.com/free <https://www.excelsiorjet.com/free>). Saxonica would continue to support development of the project and welcome contributors to help maintain and implement new features especially in PHP-specific areas of the project.

Info on the latest Saxon/C release: http://www.saxonica.com/saxon-c/index.xml <http://www.saxonica.com/saxon-c/index.xml>

I welcome your comments in this intended proposal.

kind regards,

-------------------------------
O'Neil Delpratt
Software Developer, Saxonica Limited 
Email: oneil@saxonica.com <mailto:oneil@saxonica.com>
Twitter: https://twitter.com/ond1 <https://twitter.com/ond1>
Tel: +44 118 946 5894
Web: http://www.saxonica.com <http://www.saxonica.com/>
Saxonica Community site: http://dev.saxonica.com <http://dev.saxonica.com/>
Bug tracking site: https://saxonica.plan.io/ <https://saxonica.plan.io/>
  100815
October 3, 2017 14:51 danack@basereality.com (Dan Ackroyd)
Hi O'Neil,

On 3 October 2017 at 10:04, O'Neil Delpratt <oneil@saxonica.com> wrote:
> Hi, > > We are considering submitting an RFC along the following lines and welcome your comments: > > Enhancing the existing XSLTProcessor is not an option: it has fallen too far behind for this to be viable.
That's probably true.
> Excelsior have a licensing scheme enabling the compiler to be used by open source > projects (see: https://www.excelsiorjet.com/free <https://www.excelsiorjet.com/free>).
I don't have the multiple hours available now to fully read through and comprehend all the license information, however there are some red flags from my initial reading:
> Instead, we now offer free personal licenses for that Edition to all prospects > who opt in when evaluating Excelsior JET. > .... > Evaluate Excelsior JET and get a free Standard Edition license for your personal use: > ... > If you do not wish to receive a free license, you may skip the registration and > download Excelsior JET Evaluation Packages anonymously.
Having to register and opt in to obtain a license, seems like a problem.
> Caveat #1: The Excelsior JET Runtime cannot be used in embedded systems > due to a licensing restriction.
That seems like a problem.
> Caveat #2: The Standard Edition is essentially an entry‑level variant of > the product, which means that: It is not available for OS X.
That seems like a problem. With regards to the more technical aspects of the proposal. Can you say how much bigger including all of the relevant libraries would make the PHP executable? Some people have already expressed concern at how large the default PHP executable has become. What I would suggest is, if you think the license issues can be resolved, to apply for a PECL account at http://pecl.php.net/ and start having people to start using the extension through there. Having a quick look at the extension source code, I get the impression that having more people use it could result in lots of small refinements to the implementation that should be done before the extension was ready to bring into PHP core. cheers Dan Ack
  100817
October 3, 2017 20:29 walterp@gmail.com (Walter Parker)
On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd <danack@basereality.com> wrote:

> Hi O'Neil, > > On 3 October 2017 at 10:04, O'Neil Delpratt <oneil@saxonica.com> wrote: > > Hi, > > > > We are considering submitting an RFC along the following lines and > welcome your comments: > > > > Enhancing the existing XSLTProcessor is not an option: it has fallen too > far behind for this to be viable. > > That's probably true. > > > Excelsior have a licensing scheme enabling the compiler to be used by > open source > > projects (see: https://www.excelsiorjet.com/free < > https://www.excelsiorjet.com/free>). > > I don't have the multiple hours available now to fully read through > and comprehend all the license information, however there are some red > flags from my initial reading: > > > Instead, we now offer free personal licenses for that Edition to all > prospects > > who opt in when evaluating Excelsior JET. > > .... > > Evaluate Excelsior JET and get a free Standard Edition license for your > personal use: > > ... > > If you do not wish to receive a free license, you may skip the > registration and > > download Excelsior JET Evaluation Packages anonymously. > > Having to register and opt in to obtain a license, seems like a problem. > > > Caveat #1: The Excelsior JET Runtime cannot be used in embedded systems > > due to a licensing restriction. > > That seems like a problem. > > > Caveat #2: The Standard Edition is essentially an entry‑level variant of > > the product, which means that: It is not available for OS X. > > That seems like a problem. > > With regards to the more technical aspects of the proposal. > > Can you say how much bigger including all of the relevant libraries > would make the PHP executable? Some people have already expressed > concern at how large the default PHP executable has become. > > What I would suggest is, if you think the license issues can be > resolved, to apply for a PECL account at http://pecl.php.net/ and > start having people to start using the extension through there. > > Having a quick look at the extension source code, I get the impression > that having more people use it could result in lots of small > refinements to the implementation that should be done before the > extension was ready to bring into PHP core. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > From the ExcelsiorJet FAQ Page:
Is the Excelsior JET license GPL-compatible? <https://www.excelsiorjet.com/free#> Unfortunately, no. Excelsior JET includes the Java SE API source code licensed from Oracle under OCSL Commercial Use license, which is not GPL-compatible. So even releasing our own code under the GPL won't help. LGPL is fine however. We suggest you to release the natively compiled binary under a different license, pointing out that the source code is available under the GPL. You would however need the consent of all contributors. Does new code to the core have to be GPL-compatible? Or has it changed to LGPL. This may be a showstopper. Also, the fact it only generates 32-bit code may also be a non starter, as lots of Linux & BSD systems are now running 64-bit as the default/common install. Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
  100821
October 4, 2017 17:57 davey@php.net (Davey Shafik)
On Tue, Oct 3, 2017 at 1:29 PM, Walter Parker <walterp@gmail.com> wrote:

> On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd <danack@basereality.com> > wrote: > > > Hi O'Neil, > > > > On 3 October 2017 at 10:04, O'Neil Delpratt <oneil@saxonica.com> wrote: > > > Hi, > > > > > > We are considering submitting an RFC along the following lines and > > welcome your comments: > > > > > > Enhancing the existing XSLTProcessor is not an option: it has fallen > too > > far behind for this to be viable. > > > > That's probably true. > > > > > Excelsior have a licensing scheme enabling the compiler to be used by > > open source > > > projects (see: https://www.excelsiorjet.com/free < > > https://www.excelsiorjet.com/free>). > > > > I don't have the multiple hours available now to fully read through > > and comprehend all the license information, however there are some red > > flags from my initial reading: > > > > > Instead, we now offer free personal licenses for that Edition to all > > prospects > > > who opt in when evaluating Excelsior JET. > > > .... > > > Evaluate Excelsior JET and get a free Standard Edition license for your > > personal use: > > > ... > > > If you do not wish to receive a free license, you may skip the > > registration and > > > download Excelsior JET Evaluation Packages anonymously. > > > > Having to register and opt in to obtain a license, seems like a problem.. > > > > > Caveat #1: The Excelsior JET Runtime cannot be used in embedded systems > > > due to a licensing restriction. > > > > That seems like a problem. > > > > > Caveat #2: The Standard Edition is essentially an entry‑level variant > of > > > the product, which means that: It is not available for OS X. > > > > That seems like a problem. > > > > With regards to the more technical aspects of the proposal. > > > > Can you say how much bigger including all of the relevant libraries > > would make the PHP executable? Some people have already expressed > > concern at how large the default PHP executable has become. > > > > What I would suggest is, if you think the license issues can be > > resolved, to apply for a PECL account at http://pecl.php.net/ and > > start having people to start using the extension through there. > > > > Having a quick look at the extension source code, I get the impression > > that having more people use it could result in lots of small > > refinements to the implementation that should be done before the > > extension was ready to bring into PHP core. > > > > cheers > > Dan > > Ack > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > From the ExcelsiorJet FAQ Page: > Is the Excelsior JET license GPL-compatible? > <https://www.excelsiorjet.com/free#> > > Unfortunately, no. Excelsior JET includes the Java SE API source code > licensed from Oracle under OCSL Commercial Use license, which is not > GPL-compatible. So even releasing our own code under the GPL won't help. > LGPL is fine however. > > We suggest you to release the natively compiled binary under a different > license, pointing out that the source code is available under the GPL. You > would however need the consent of all contributors. > Does new code to the core have to be GPL-compatible? Or has it changed to > LGPL. This may be a showstopper. > > Also, the fact it only generates 32-bit code may also be a non starter, as > lots of Linux & BSD systems are now running 64-bit as the default/common > install. > > > Walter >
You seem to be mistaken in thinking the PHP project is GPL licensed. It is in fact licensed under the PHP License[1], and AFAIK does not allow GPL-licensed in core (LGPL is fine)… [1] http://php.net/license/3_0.txt
  100822
October 4, 2017 18:23 walterp@gmail.com (Walter Parker)
On Wed, Oct 4, 2017 at 10:57 AM, Davey Shafik <davey@php.net> wrote:

> On Tue, Oct 3, 2017 at 1:29 PM, Walter Parker <walterp@gmail.com> wrote: > >> On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd <danack@basereality.com> >> wrote: >> >> > Hi O'Neil, >> > >> > On 3 October 2017 at 10:04, O'Neil Delpratt <oneil@saxonica.com> wrote: >> > > Hi, >> > > >> > > We are considering submitting an RFC along the following lines and >> > welcome your comments: >> > > >> > > Enhancing the existing XSLTProcessor is not an option: it has fallen >> too >> > far behind for this to be viable. >> > >> > That's probably true. >> > >> > > Excelsior have a licensing scheme enabling the compiler to be used by >> > open source >> > > projects (see: https://www.excelsiorjet.com/free < >> > https://www.excelsiorjet.com/free>). >> > >> > I don't have the multiple hours available now to fully read through >> > and comprehend all the license information, however there are some red >> > flags from my initial reading: >> > >> > > Instead, we now offer free personal licenses for that Edition to all >> > prospects >> > > who opt in when evaluating Excelsior JET. >> > > .... >> > > Evaluate Excelsior JET and get a free Standard Edition license for >> your >> > personal use: >> > > ... >> > > If you do not wish to receive a free license, you may skip the >> > registration and >> > > download Excelsior JET Evaluation Packages anonymously. >> > >> > Having to register and opt in to obtain a license, seems like a problem. >> > >> > > Caveat #1: The Excelsior JET Runtime cannot be used in embedded >> systems >> > > due to a licensing restriction. >> > >> > That seems like a problem. >> > >> > > Caveat #2: The Standard Edition is essentially an entry‑level variant >> of >> > > the product, which means that: It is not available for OS X. >> > >> > That seems like a problem. >> > >> > With regards to the more technical aspects of the proposal. >> > >> > Can you say how much bigger including all of the relevant libraries >> > would make the PHP executable? Some people have already expressed >> > concern at how large the default PHP executable has become. >> > >> > What I would suggest is, if you think the license issues can be >> > resolved, to apply for a PECL account at http://pecl.php.net/ and >> > start having people to start using the extension through there. >> > >> > Having a quick look at the extension source code, I get the impression >> > that having more people use it could result in lots of small >> > refinements to the implementation that should be done before the >> > extension was ready to bring into PHP core. >> > >> > cheers >> > Dan >> > Ack >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> From the ExcelsiorJet FAQ Page: >> Is the Excelsior JET license GPL-compatible? >> <https://www.excelsiorjet.com/free#> >> >> Unfortunately, no. Excelsior JET includes the Java SE API source code >> licensed from Oracle under OCSL Commercial Use license, which is not >> GPL-compatible. So even releasing our own code under the GPL won't help. >> LGPL is fine however. >> >> We suggest you to release the natively compiled binary under a different >> license, pointing out that the source code is available under the GPL. You >> would however need the consent of all contributors. >> Does new code to the core have to be GPL-compatible? Or has it changed to >> LGPL. This may be a showstopper. >> >> Also, the fact it only generates 32-bit code may also be a non starter, as >> lots of Linux & BSD systems are now running 64-bit as the default/common >> install. >> >> >> Walter >> > > You seem to be mistaken in thinking the PHP project is GPL licensed. It is > in fact licensed under the PHP License[1], and AFAIK does not allow > GPL-licensed in core (LGPL is fine)… > > [1] http://php.net/license/3_0.txt >
Sorry, my mistake. I didn't notice when PHP changed from GPL style to BSD style. I withdraw my comments on the the GPL issue. Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
  100826
October 5, 2017 15:03 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
On Mi, 2017-10-04 at 11:23 -0700, Walter Parker wrote:
> Sorry, my mistake. I didn't notice when PHP changed from GPL style to > BSD style. >
Hard to remember, since that happened already during the last century (with PHP 3 in 1997) ;-) And yes, LGPL modules are tolerable, but not liked. GPL is not possible. See http://php.net/license/ About saxon: To my understanding libsaxon is not available on many systems (for Ubunut Io nly find saxon-java, not saxon/c https://package s.ubuntu.com/search?keywords=saxon&searchon=names&suite=zesty§ion=a ll) this makes me doubtful whether saxon/c really is "a recognized leader" as the marketing blurb in the original mail states. (while I'm not knowledgeable about the state of the XML/XSLT world) I tried to download the thing from http://www.saxonica.com/download/c.x ml which is a slow server and the only thing inside the tarball was a single executable, so I gave up. In practical terms bundling in php-src doesn't win you much: Vast majority of users  uses PHP from distros. Distros like to split it up into small packages, especially if there are external dependencies. For a user it doesn't matter if they have to type "apt-get install php- saxon" or i.e. "apt-get install php-pecl-saxon" whereas when releasing via pecl you're not bound to PHP's release cycle, backwards compatibility etc. thus you can innovate at your pace. johannes.