Re: [xml] XPath 2, XSLT 2

[Steve Ball <Steve Ball explain com au>]

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.

Regards,
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
> > http://www.explain.com.au/libx/.
> >
> > 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
> > http://www.explain.com.au/libx/programmes.html. 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
> > difficult.
> >
> > 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
> end.
> 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
>
> --
> Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
> daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
> http://veillard.com/ | virtualization library  http://libvirt.org/