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

Subject: Re: [xsl] Definite list of XSLT 2.0 processors?
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Tue, 19 Jan 2010 09:55:02 -0800
Wendell,

> * On the other hand, I do think there is a need for XSLT 2.0 in C/C++,

I didn't say there was no need for new XSLT 2.0 processors -- just
that the need is for good ones  :)


Cheers,
Dimitre

On Tue, Jan 19, 2010 at 8:23 AM, Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
wrote:
> 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 B  B  B  B  B  B  B  B  B  B  B  B  B 
B mailto:wapiez@xxxxxxxxxxxxxxxx
> Mulberry Technologies, Inc. B  B  B  B  B  B  B 
B http://www.mulberrytech.com
> 17 West Jefferson Street B  B  B  B  B  B  B  B  B  B Direct Phone:
301/315-9635
> Suite 207 B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B 
B Phone: 301/315-9631
> Rockville, MD B 20850 B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  Fax:
301/315-8285
> ----------------------------------------------------------------------
> B Mulberry Technologies: A Consultancy Specializing in SGML and XML
> ======================================================================
>
>



--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
I enjoy the massacre of ads. This sentence will slaughter ads without
a messy bloodbath.

Current Thread