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/
Hi O'Neil,
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
Hi O'Neil,
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--
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
On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd danack@basereality.com
wrote:Hi O'Neil,
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--
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)…
On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd danack@basereality.com
wrote:Hi O'Neil,
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--
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)…
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
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.
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.