Fwd: Re: [xsl] Future of XSL Stylesheet Writing?

Subject: Fwd: Re: [xsl] Future of XSL Stylesheet Writing?
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 28 Sep 2007 14:36:38 +0200
(third attempt)

Date: Fri, 28 Sep 2007 11:36:35 +0200
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx, xsl-list@xxxxxxxxxxxxxxxxxxxxxx
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: [xsl] Future of XSL Stylesheet Writing?

(RETRY ATTEMPT)

Date: Fri, 28 Sep 2007 09:51:28 +0200
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx, xsl-list@xxxxxxxxxxxxxxxxxxxxxx
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
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@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 Jul'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Current Thread