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(_at_)adam(_dot_)com(_dot_)au> wrote:
Andrew Welch wrote:
2010/1/18 Justin Johansson <procode(_at_)adam(_dot_)com(_dot_)au>:
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. The scale of difficulty involved in such a
project (esp. XSLT 2.0 versus XSLT 1.0) certainly cannot be over-estimated.
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--