Re: [xsl] Definite list of XSLT 2.0 processors?

Subject: Re: [xsl] Definite list of XSLT 2.0 processors?
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 19 Jan 2010 11:23:20 -0500
Justin,

To both counter and corroborate what Dimitre says:

* I agree that Saxon sets a very high bar, both in terms of the quality of the product, and important determinants such as standards conformance, responsiveness to users with features and bug fixes, support and so forth. This, in combination with its affordability, makes it a tough market to enter.

I don't think I'm alone in being in awe of Mike Kay for his accomplishment; but I also imagine he would be ready to acknowledge that he has been able to leverage certain externalities in doing his work -- for example, the candid support of a strong and healthy user community not in the shadow of any particular software empire. (Dimitre, for example, may not have paid for Saxon until recently; but he has surely helped in other ways.) I should hope that other developers might also benefit from factors like this.

* On the other hand, I do think there is a need for XSLT 2.0 in C/C++, notwithstanding the coolness of the LAMP community. One might expect them to think differently, but they have always done things their own way and will continue to. More importantly, the applications they most typically deal with (think of a web site backed by an RDBMS, with no strong need for data reuse outside the app) simply can't take advantage of XSLT to the same extent that document processing and publishing systems do. As the technologies continue to develop -- as more open e-book platforms come on line, web authoring applications such as wikis face interoperability requirements, and publishing applications in general mature (they can be very slow to grow) -- the future looks bright for XSLT.

In fact I know of at least one *large* and *significant* publisher on the Internet that has been very slow to embrace XSLT 2.0 for the simple reason that they don't want to run their mission-critical applications in Java. People tell them this is not, or no longer, a good reason to deny themselves. But for the usual reasons, a high-level policy decision made ten or twelve years ago, having become part of the culture, is hard to change. Their developers just don't do Java.

This kind of thing makes me think that when a reasonably good XSLT 2.0 processor for the Java-allergic emerges (and this camp includes independent Linux adherents as well as big shops), at the right price on the right platform(s), I think it will be used, and used widely, even next to Saxon.

Nor does a market opportunity like this stay open forever. The announcement could be made tomorrow.

Cheers,
Wendell

At 09:15 AM 1/19/2010, you wrote:
Hi Justin,

So, you want to know if we need yet another XSLT processor (in C,
C++): certainly, if it is better than what we already have.

I will convert to an XSLT processor if it manages to put Saxon in the
dust and has same or better level of compliance and interoperability.
Service, support, response to users are also very significant factors
that Saxon has made challenging to exceed. Not to mention the prompt
implementation of the new features from the latest W3 working drafts.


======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

Current Thread