4.1 XSLT history
For a technical standard, XSLT has had a surprisingly convoluted history. It was born as part of the Extended Stylesheet Language (XSL), envisioned as a comprehensive technology for presentation of XML documents. Like the DSSSL International Standard that inspired it, XSL divides the formatting process into two stages: First, the source XML tree is transformed into a target tree representing the formatted document, and second, the target tree is rendered for viewing.
XSLT was created as the transformation part of XSL. As it shared with the XPointer and XLink standards the need to specify arbitrary subsets of the source tree, its addressing language was separated into an independent specification called XPath. The XSLT 1.0 and XPath 1.0 specifications were published simultaneously in November 1999.  The XSL formatting vocabulary, unofficially called "XSL Formatting Objects (XSL-FO)," was published as XSL 1.0 in October 2001.
 www.w3.org/TR/xslt, www.w3.org/TR/xpath
Originally, XSLT was intended to transform arbitrary XML into the XSL-FO vocabulary. Some experts say this fact proves that XSLT cannot be a universal XML transformation language.  Nevertheless, since no other technology offered the same compelling blend of XPath, template-based processing, and the endorsement of the W3C, XSLT quickly grew in popularity. Despite its limitations, XSLT is widely used nowadays for all kinds of XML-to-XML transformations.
 Much like the experts who claimed that science proves bumblebees to be incapable of flight. In both cases, real-world experience suggests the contrary (see www.math.niu.edu/~rusin/known-math/98/bees).
Limitations? What limitations? Two things are usually considered to be the fundamental limitations of XSLT.
One is inherent in the data model of XSLT. In order to provide arbitrary XPath access to the source tree, the entire source document must be parsed and loaded into memory before you can begin your transformation. For small documents it is not a problem, but as your documents grow, processing becomes not only slow but precipitously slow (as soon as swapping starts) or even impossible (when both RAM and swapping space on your system are exhausted). This limitation can sometimes be worked around by preceding the XSLT transformation in your toolchain with a script that breaks input documents into manageable chunks (this is more likely to work for database-like structures, 1.2 ).
The second limitation is more like "a feature, not a bug." XSLT was designed as a functional programming language, and as such it has no variable assignment operator. You can create as many variables as you wish within any scope, but once a variable is defined, you cannot change its value within the same scope. This causes quite some trouble to beginner XSLT programmers who have had previous experience with traditional (i.e., nonfunctional) programming languages such as C or Perl. However, as we'll see below ( 4.3 ), you can write efficient and elegant (or at the very least, efficient or elegant) stylesheets without any assignable variables.
Despite these limitations, for the task we're interested inXML-to-HTML transformationXSLT is nearly perfect. And where it's not, you can always plug in your own custom extensions ( 4.4.3 ).
XPath as a guest musician. The applicability domain of XPath is wider than that of XSLT. Libraries exist that allow one to use XPath to access XML data from other programming languages, such as Python or Perl. Moreover, XPath has inspired several minor but nifty scripting and shell languages, such as XPathScript  and xsh  ( 220.127.116.11 ). Some XML editors and IDEs offer built-in XPath engines for searching and navigating in documents ( 18.104.22.168 ).
Beyond 1.0. After cranking out versions 1.0 of XSLT and XPath, the W3C did not take a vacation. Processors based on the Working Drafts had already been actively used, and the work on the next version of the standard began immediately. Numbered 1.1, this new version included a handful of the features most obviously missing from 1.0in particular,
the ability to create multiple output documents;
the ability to define extension functions in arbitrary languages inside the stylesheet (using the xsl:script instruction, similar to the script element of HTML);
several syntactic and semantic changes intended to make the language simpler and more consistent.
It was the second of these features that proved the most controversial . Some XSLT experts even claimed that XSLT was poised to go the way of HTML, as people would rush to create incompatible extensions in nonstandard languages and few stylesheets would be able to run on more than one processor. Partly because of this reaction and partly out of the realization that XSLT needed a much deeper overhaul , the 1.1 draft was abandoned and the work on 2.0 started instead.