Re: [xml] XPath 2, XSLT 2

Hi Daniel,

Firstly, thanks for your support and encouragement. As you, and others, are aware the development model outlined in my message was not my first choice to undertake this work. I completely understand that you must point out the risks of this approach.

I've been developing and managing open source software projects for many years (eg. the XSLT Standard Library and others), so I know that it is more than just a licence. I also know the value of quality software engineering and what it takes to achieve high quality.

An important aspect of the plan that I am working to is to merge the XPath 2/XSLT 2 code back in to the main libraries, for reasons that should be obvious. If that were not the case then I'd just fork the code and get on with it (I also considered writing an XSLT 2 implementation from scratch, but libxml2 has great value that I don't want to lose so I quickly dismissed that plan). I'll work with you to make sure that the code quality is acceptable - that's the best-case scenario.

Open Source is not incompatible with commercialism. I take as an example what ActiveState does for Perl, Python and Tcl. What I am hoping to do is setup something that complements and supports the open source libxml2/libxslt project.

Steve Ball

On 27/11/2008, at 9:45 PM, Daniel Veillard wrote:

On Wed, Nov 26, 2008 at 07:01:52AM +1100, Steve Ball wrote:
First the good news: I've started working on implementing XPath 2 in
libxml2 and XSLT 2 in libxslt. The first thing I've tackled in XPath 2
is sequences. The library can now parse the following expressions and
returns the correct result:

count(("a", "b", "c"))            := 3
count(("a", 2, 3.0, "d"))           := 4
count(/)                                        := 1
count(/*)                                       := 1
count((/*))                             := 1
count((/, /*))                          := 2
count((//p, //chapter))         := 7

xmlSequence has been added as an object type, in addition to the
existing types, including xmlNodeSet and value tree. The reason for this
is to maintain backward-compatibility (which is require for XSLT
backward-compatible processing mode). The existing XPath APIs implement
XPath 1 syntax and semantics. I've added a new API to create an XPath
parser with XPath 2 syntax. This means that existing applications will need to be updated to use XPath 2; by default they will continue to use
XPath 1.

On the XSLT 2 front I've started work on implementing xsl:for-each-
group. Of the four grouping algorithms the first to be implemented will
be group-adjacent. From the work I've done with XSLT 2 so far, this
feature is one of the most profound improvements over XSLT 1, so there
will be a lot of bang for the buck.

Now for the not bad, but interesting news! Since no one else is
volunteering their time to do this work, I've decided to see if anyone
will volunteer their money instead. I've setup a project within my
company to undertake this development and to fund it we are offering a suite of professional services. You can read more details about this at

When the XPath 2 and XSLT 2 implementation has been completed all of
that code will be contributed back to the Gnome libxml2/libxslt project. In the meantime, to get early access to the code you can sign-up for our
Professional Developers Programme, see You can join as an
individual, or businesses can join up to get access for multiple
employees. The more people and businesses join up, the more resources
I'll have to further work on the XPath 2/XSLT 2 implementation.

Reporting on progress to the general community with messages like this
one will be irregular. However, there will be a regular and detailed
reports to members of the Professional Developers Programme.

Once the implementation is complete I'm planning on going further by
creating a product that offers features beyond those in the XPath and
XSLT standards. This will include transparent features, such as
performance optimisations, as well as custom extensions. I'll know the
code pretty well by then, so providing professional services, such as
support, customisations and application development, won't be too

I hope the community finds my approach to funding this work acceptable.
If you don't like it, then feel free to send me a message (preferably
along with an offer to help). If you don't mind it but don't have the
money then feel free to send a message of encouragement (and tell your
friends and neighbours to sign up ;-).

It's an interesting approach, but I absolutely cannot garantee any of
that code will be merged in libxml2 as a result of the development
model. You seems to have the right ideas on how to roll this out
technically, but unless everybody has a chance to review it publicly,
there is zero garantee that this would be acceptable or usable in the
I would like to give a better feedback, because obviously you're
investing time in the libraries, but open source is a proces, not just
a licence, the quality and fitness to purpose that is the merit of
a lot of OSS is basically the result of that process, the Licence allows
the process but is not in itself the cause of the quality.
Like any development behind closed doors, you simplify the funding,
but you loose the peer review which is IMHO the key to the quality
and insurance that it will fit the end-users needs (in a relatively
complete model like XSLT though the needs are defined in the model
so in that case there is less effect on that point).

It's sad that people don't have time to really contribute XPath2/XSLT2
publicly, your approach is clearly due to that failure. I appreciate you
try to find a way to overcome this limitation, but I must make clear
that what you're doing and what people may invest in, might not be part
of libxml2 or libxslt releases in the end. Assuming the worse and we
really find the code or something else like licencing to be too
problematic then you would still have the opportunity to ship this
independantly (or fork libxml/libxslt), but that's really not like
being part of the releases, and that unfortunately can only be garanteed
by publishing the code.
Maybe in the end the code will be mergeable, I hope the outcome will
be positive, but I have to raise the risks of this approach, doing so
is IMHO part of my maintainer duties.

 I still wish the best to this project even if I can't really approve
the development model.


Daniel Veillard      | libxml Gnome XML XSLT toolkit
daniel veillard com  | Rpmfind RPM search engine | virtualization library

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]