[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Fwd: Re: Future of XSL Stylesheet Writing?

Subject: Fwd: Re: Future of XSL Stylesheet Writing?
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 28 Sep 2007 14:36:38 +0200
Fwd: Re:  Future of XSL Stylesheet Writing?
(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:  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:  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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2011 All Rights Reserved.