[XSL-LIST Mailing List Archive Home]
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
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.
At 09:15 AM 1/19/2010, you wrote:
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