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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Obstacles (?) to XSLT 2.0, Vyacheslav Sedov | Thread | Re: [xsl] Obstacles (?) to XSLT 2.0, Justin Johansson |
Re: [xsl] Obstacles (?) to XSLT 2.0, Andrew Welch | Date | Re: [xsl] Obstacles (?) to XSLT 2.0, Justin Johansson |
Month |