RE: xslt 2.0 and alternatives?

> I've been working with XSLT 2.0, which currently means Saxon. 
>  I wonder 
> what I ought to be telling people who might be interested in 
> integrate 
> processing into a C or C++ project?

Mixing components in different languages within the same application has
been done many times before and will be done many times again. It's not an
ideal answer, because it's always extra work to do the integration, but it's
often the only answer there is.

Consider implementing the transformation as a web service and invoking it
from the client application via HTTP calls. The client need never know that
the transformation is done using XSLT, let alone that it's done using an
XSLT processor written in Java.
 
> If that isn't a realistic medium-term option, then how to think about 
> using the work I've done in that sort of environment?  The most 
> significant functionality enabled by 2.0 is the temporary tree stuff 
> that sorts and enhances my data, and the related multi-level grouping 
> operations.  

It's probably always true that if you work hard enough, you can code the
transformation in XSLT 1.0 plus vendor extensions where needed. But the work
may often be greater than the mixed-language solution.

Michael Kay
http://www.saxonica.com/