[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] What is the Core of XSLT?

Subject: [xsl] What is the Core of XSLT?
From: "Abel Braaksma (Exselt)" <abel@xxxxxxxxxx>
Date: Sat, 29 Mar 2014 17:51:13 +0100

(continuing on another thread, as I seem to have shift subjects)

For the previous thread, search for "[xsl] Things that make you go Hmmmm!".

On 29-3-2014 16:41, Ihe Onwuka wrote:
> The syntactical minimalism, brevity of language specification and
> power of functional languages derives IMHO from the extensive
> application of orthogonality.

I agree, with respect to functional languages.

However, there is a difference between functional languages and XSLT.
With (most?) functional languages, there is a core language that is
extremely minimalistic, and there's a language extension or set of
libraries that expands on that to prevent that everyone has to write
these themselves. A strong part of such core languages that allows this
sort kind of design is (re)definition of operators and functions,
overloads and overrides, things currently not allowed in XSLT. The
orthogonality of the core language is not necessarily applicable to its
libraries (see for instance .NET vs F#).

For XSLT, the language and the later extensions are deeply interwoven
into one another. Whether this is fortunate or not I cannot say, but it
is the way it has evolved. For any (future) discussion on language
design, I think it would make sense to distinguish between core language
features (which are few) and later additions and extensions (which could
fall into the category of libraries, i.e. comparable to .NET and
function/operator overrides in the case of F#).

Here is an attempt to make such distinction, trying to leave out any
other constructs that can be written using just these base constructs.
These are (but I have to admit, I have no proof that this is complete):



I left xsl:output out because it is itself already an extension (not all
XSLT processors produce output), and conversely, most languages provide
library functions for output. Same is true for xsl:message, which I
consider a library function for tracing messages.

I left xsl:for-each out because it can also be expressed in
xsl:apply-templates/call-templates syntax (not sure this is always the
case though, I do a bit of hand-waiving here).

I left xsl:copy-of out because it is a subset of xsl:copy.

Note that xsl:if is not required, it can be expressed in xsl:choose, but
I left it in because just about any language out there has an
if-statement (albeit different, we just have an if-statement, no
if-then-else in XSLT).

Obviously, XSLT cannot work without a data selection language, which in
this case is XPath, but I am not going to attempt a minimal subset of
that too.

I would be interested what people's opinions are on such minimal subset
that can be used to express all other language constructs of the XSLT
language, be it 1.0, 2.0 or 3.0.


Abel Braaksma
Exselt XSLT 3.0 processor

Current Thread