At 2008-06-21 21:06 +0200, James Fuller wrote:
anyhow, its interesting to see that jquery sometime late 2007 surpassed xslt
http://www.google.com/trends?q=xslt%2C+jquery&ctab=0&geo=all&date=all&sort=0
xslt versus xquery shows that xquery is either so easy to learn that
no one needs to use google, or there is a lack of xquery content
http://www.google.com/trends?q=xslt%2C+xquery&ctab=0&geo=all&date=all&sort=0
Or perhaps XML is being used more these days for element content
rather than mixed content and the "pull model" of XQuery satisfies
those who do not need the "push" model of XSLT. Learning XSLT covers
off both pull and push, so my money is still on XSLT as the
technology to learn ... though I'm sure you won't hear that from
XQuery vendors.
For publishing solutions with XSL-FO my customers invariably are
using mixed content, so XQuery doesn't even come into the
equation. For others using element content only, they may not be
aware of the modularity schemes of XSLT in stylesheet maintenance and
deployment, and that XSLT stylesheets are conforming XML documents.
In all my customers' major projects I use my XSLStyle documentation
methodology with my XSLT import trees of a dozen or more fragments
... all because the XSLT files are themselves XML and suitable for
XSLT transformation into the Javadoc-like documentation. XSLStyle is
an embedded documentation framework that allows any off-the-shelf
vocabulary to be used for XSLT documentation ... it is delivered with
support for DocBook and DITA and I have customers using each of
these. On one project I used it recursively where the stylesheets
for the US Intelligence Document XML vocabulary were documented using
the vocabulary itself: you apply the stylesheets to themselves in
order to produce the documentation. It also gave the development
team practice using the vocabulary they were supporting.
Given that XQuery documents are not XML documents, this wouldn't be possible.
I don't think XSLT is going to die off any time soon, and I foresee
only growing acceptance for it.
and just to see xslt in context with general web programming languages
http://www.google.com/trends?q=xslt%2C+ruby%2C+php%2C+perl&ctab=0&geo=all&date=all&sort=0
Horses for courses ... programming problems differ, so I think that
is an unfair comparison. I hope none of my customers ask me to
implement a publishing solution in C++ or even Python.
Do any of these trends indicate anything with respect to peaking XSLT
adoption ? ... considering these numbers I wonder if XSLT 2.0
adoption will be a very slow burn ?
Not from what I'm seeing. All my customers projects have moved to
XSLT 2.0 and my XSLT 2.0 in-house training has been very
popular. Not sure why the publicly-subscribed XSLT and XSL-FO
training has been slow to catch on. We had a great class in Austin
in January, but no demand for it since. I'm trying New Zealand next
January as a new market opportunity to see if there is interest in
XSLT 2.0 and XSL-FO 1.1 publicly-subscribed training, but the initial
response has been disappointing and I may have to try
Australia. Training, however, is susceptible to business slowdown
and currency exchange sensitivities (my non-North American training
is billed in Euros) so I'm sure that is impacting it as well.
So, in conclusion, I believe any investment made in XSLT 2.0 won't be a waste.
I hope this helps!
. . . . . . . . . . . . Ken
--
Upcoming XSLT/XSL-FO hands-on courses: Wellington, NZ 2009-01
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds: publicly-available developer resources and training
G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal