(third attempt)
Date: Fri, 28 Sep 2007 11:36:35 +0200
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com,
xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: "G. Ken Holman" <gkholman(_at_)CraneSoftwrights(_dot_)com>
Subject: Re: [xsl] Future of XSL Stylesheet Writing?
(RETRY ATTEMPT)
Date: Fri, 28 Sep 2007 09:51:28 +0200
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com,
xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: "G. Ken Holman" <gkholman(_at_)CraneSoftwrights(_dot_)com>
Subject: Re: [xsl] Future of XSL Stylesheet Writing?
At 2007-09-28 09:20 +0200, James Fuller wrote:
I will guess that XSLT will remain relevant for the next 3-4 years,
with 7 years being the 'horizon of relevant usage' tailing off past
that time (critical systems going into maintenance mode will always
need experts to maintain).
I thought the same thing in February 1999 when I started teaching
XSL before it became finalized. I've been pleasantly surprised.
There are always other factors that determine successful software, and
usually change is imposed by fundamental shifts in hardware. I
believe these fundamental hardware improvements will eventually push
us into using languages that are designed for parallel processing;
which may mean that XSLT loses out.
But XSLT is designed for parallel processing ... why would you think
XSLT loses out? XSLT language design decisions support template
rules for matched nodes being processed in parallel and
asynchronously with the result tree fragments being assembled in the
appropriate final order regardless of the order in which the
fragments are actually created. This paradigm can take advantage of
as many parallel processes as there are nodes selected in an
<xsl:apply-templates/> instruction.
I think complaints from so many classical programmers (as I used to
classify myself) of the side-effect-free programming style of XSLT
(such as using variables that do not vary) would be lessened if
there was more awareness that such design decisions support parallel
processing implementation.
So, I see XSLT in ascension as parallel processing becomes more
prevalent ... where will XQuery go, where will SAX go, and where
will DOM go? These are all pull-oriented and single process
based. What other XML processing paradigm is as well designed for
parellelized implementation as the XSLT push model of
apply-templates and template matches?
Yet another reason to promote the push-oriented style of XSLT
stylesheet writing over the pull-oriented style.
I hope this helps.
. . . . . . . . . . . . Ken
--
Upcoming public training: UBL and code lists Oct 1/5; Madrid Spain
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds: publicly-available developer resources and training
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Cancer Awareness Jul'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
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>
--~--