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

Subject: RE: [xsl] Obstacles (?) to XSLT 2.0 in C++
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Fri, 11 Dec 2009 09:22:12 -0000
Interesting question, and as you suggest, I think there is a mix of
technical and commercial reasons.

I've seen a number of projects (several of them ultimately unsuccessful)
where people have attempted to implement XSLT in C++, and I am convinced
that it is a considerably harder task than implementing in Java, largely
because of the complexity of doing your own memory management. But of course
it can be done and it has been done.

But the underlying reasons are commercial. It's too big a project for
amateurs to do in their spare time, and the return on investment is hard to
justify for commercial companies with a traditional business model. It's
much easier for both groups to justify starting an XQuery project - the
language is smaller, and the field is new, so it's easy to delude yourself
and your financial backers that you are going to make a killing. The fact
that Saxon is so far ahead in the race also makes it more difficult for
others to enter, although there's a clear gap in the market for a good
product that runs in the LAMP and/or native Windows environments. The
problem is that users today have a high expectation that a product for those
platforms should be free.

Regards,

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

> -----Original Message-----
> From: Justin Johansson [mailto:procode@xxxxxxxxxxx] 
> Sent: 11 December 2009 08:13
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: [xsl] Obstacles (?) to XSLT 2.0 in C++
> 
> 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

Current Thread