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

[Dimitre Novatchev <dnovatchev@xxxxxxxxx>]

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.


--
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




On Tue, Jan 19, 2010 at 3:52 AM, Justin Johansson <procode@xxxxxxxxxxx>
wrote:
> Andrew Welch wrote:
>>
>> 2010/1/18 Justin Johansson <procode@xxxxxxxxxxx>:
>>
>>>
>>> Hi Andrew,
>>>
>>> Yes, well, my response to Vyacheslav was a tad rhetorical.
>>>
>>> So let's rephrase my original quandary yet again.
>>>
>>> "Given the neglect (i.e. XSLT for anything else other than Saxon/Java
>>> (notwithstanding .Net autoport)),
>>> does *any other* community really want one?"
>>>
>>
>> As was mentioned earlier in the thread, Intel and IBM both have their
>> own commercial xslt 2.0 processors, and MarkLogic is adding xslt 2.0
>> support in version 5... (because of popular demand)
>>
>> Everyone wants XSLT 2.0, it's the best!
>>
>>
>
> First, thanks to all for replies to my inquiry on this thread and also many
> thanks to Abel Braaksma for seeding this discussion.
>
> Yay, Andrew, I don't need any convincing of, as you say, "XSLT 2.0, it's
the
> best" :-)
>
> What I was hoping for was more convincing that there are real gaps in the
> "market" for XSLT 2.0 engines and particularly in the C/C++ implementation
> space.
>
> Sadly, having inquired on various online forums and pursued some offline
> market research into the demand for a decent XSLT 2.0 implementation for
the
> LAMP environment, I've been unable to positively identify such a real need
> as would be compelling enough to provoke the investment of time and money
to
> develop and realize the same. B The scale of difficulty involved in such a
> project (esp. XSLT 2.0 versus XSLT 1.0) certainly cannot be over-estimated.
> B Nevertheless, with a little encouragement I'd like to be able to add a
new
> XSLT 2.0 processor to Abel's list for 2010 and to complete such project
> which I've been slowly chipping away at for a few years now.
>
> Regards
>
> Justin Johansson