Re: [xsl] Obstacles (?) to XSLT 2.0 in C++

[Steve Ball <Steve.Ball@xxxxxxxxxxxxxx>]

Back in 2008 someone asked on the libxml2 mailing list whether XPath 2.0 and
XSLT 2.0 would be supported. Daniel Veillard responded:

> Sorry, no support for 2.0 planned, the spec change is far too big and
> intrusive. Look at the EXSLT extensions which are supported by libxslt
> and xsltproc, they are likely to provide the needed extensions.

libxml2/libxslt is a fundamental building block for my software, and XSLT 2.0
is very compelling (a lot of the stylesheets that I write need
xsl:for-each-group), so I tried to gather interest in starting a subproject to
do the implementation. A few people responded saying that would love to have
XSLT 2.0 in libxslt, but didn't have the time to commit to getting it done.

After that, I thought if people can't commit their time perhaps they can
commit their money. I started the "LIBX" project as a commercial venture to
implement XPath 2.0 and XSLT 2.0 and (eventually) merge it in to the core
library. LIBX has been setup to sell this as a service, and the plan is to one
day produce a product.

The grand total of contributions so far is $100.00. With my contracting work,
I make that amount of money before I even rub the sleep from my eyes in the
morning ;-) Interesting, I only got that contribution because someone asked to
provide an up-to-date compilation of libxml2 for the iPhone (the Apple
supplied library is a few versions behind).

This experience leads to my conclusion that very few, if any, folks are
willing to pay for base technology. However, they are willing to pay for
"solutions".

Accordingly, my current approach is now to develop a product that solves some
sort of high-level problem, but that would benefit from having a C-based XPath
2.0 and XSLT 2.0 implementation. This product is Packaged Press - a DIY
ePress. What it really is is an XProc pipeline controller, implemented on top
of libxml2/libxslt. Currently, the XProc implementation will be restricted to
XPath 1.0; of course, the plan is to add XPath 2.0 to libxml2 at some stage in
the future. My hope is that sales of the product will fund development of the
library changes for XPath 2.0 support.

So, Justin, I don't think lack of garbage collection has anything to do with
the paucity of implementations in C/C++. As Mike Kay has already said, it has
everything to do with commercial realities. In case of libxml2, the people
that really matter believe XSLT 1.0 is good enough and there is a strong
perception that XSLT 2.0 is too difficult (not a viewpoint I share - but it
does involve a non-trivial amount of engineering).

Cheers,
Steve Ball

On 11/12/2009, at 7:12 PM, Justin Johansson wrote:

> Hi XSLT people,
>
> I'm wondering just what exactly-one or more (pun intended) obstacles there
are to having XSL-T 2.0, XPath 2.0 and friends implemented in C++.
>
> (I assert that) It is desirable to be able to manipulate XML in both pull
and push fashion.  My understanding (please correct me if I am wrong) is that
XQuery is as to pull as XSL-T is as to push.  Yes there are many XQuery opi in
progress for a multitude of platforms including Java, .Net and various FP
languages and some with a C/C++ language base.  On the other hand, XSL-T 2.0
is as good as still-born (to quote a blog by Elliotte Rusty Harold) given that
there are few if any C++ based XSL-T processors that approach anywhere near
the Gold Standard XSL-T 2.0 processor that is Saxon for Java (and its .Net
translation).
>
> So just what are the obstacles, impediments, show-stoppers etc. for
world-class XSL-T 2.0 processors in the C/C++ space?
>
> I'm very interested in feedback from this list.  Perhaps some plausible
issues include:
>
> - Lack of inbuilt garbage collection in C/C++ (which is very much a
requirement when dealing with the list/sequence nature of XPath) makes
implementation difficult
>
> - The spec(s) is(are) difficult to master so no matter what language
prospective implementors are reluctant to take on the Gold Standard
>
> - There are no compelling reasons for business investment in alternative
XSL-T implementations
>
> - XML processing libraries for C/C++ are disparate; where is XOM for C++ for
instance?
>
> - XSL-T 1.0 is sufficient so who cares?
>
> - I'm clueless; please add your input
>
> Thanks for all replies,
>
> Justin Johansson