Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] RFC proposal: Provide support for XSLT 3.0, XPath 3.1, and XQuery 3.1

Posted by 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:[email protected]>
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,

On 3 October 2017 at 10:04, O'Neil Delpratt <[email protected]> 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
On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd <[email protected]> wrote:

> Hi O'Neil,
>
> On 3 October 2017 at 10:04, O'Neil Delpratt <[email protected]> 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
[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 <[email protected]> wrote:
>>
>> On 3 October 2017 10:04:57 BST, O'Neil Delpratt <[email protected]> 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
On Tue, Oct 3, 2017 at 1:29 PM, Walter Parker <[email protected]> wrote:

> On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd <[email protected]>
> wrote:
>
> > Hi O'Neil,
> >
> > On 3 October 2017 at 10:04, O'Neil Delpratt <[email protected]> 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
On Wed, Oct 4, 2017 at 10:57 AM, Davey Shafik <[email protected]> wrote:

> On Tue, Oct 3, 2017 at 1:29 PM, Walter Parker <[email protected]> wrote:
>
>> On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd <[email protected]>
>> wrote:
>>
>> > Hi O'Neil,
>> >
>> > On 3 October 2017 at 10:04, O'Neil Delpratt <[email protected]> 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
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&section=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. 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login