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

Re: [xsl] What is the Core of XSLT?


Subject: Re: [xsl] What is the Core of XSLT?
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Sat, 29 Mar 2014 10:44:31 -0700

First a general remark:

  It is well-known that the modern Number theory can be entirely
expressed using only the seven Peano axioms. Do we need something
similar for a programming language? I feel split on this. For
theoretical purposes it would definitely be very niceto have such a
small base of language elements, from which all other language
constructs can be expressed. I am not sure if having such clearly
defined base could be of any practical importance.

> xsl:if
> xsl:choose

These two XSLT instructions aren't necessary part of a ultimate
kernel. One can achieve what they do using <xsl:apply-templates>, a
predicate in its select attribute (necessary only in XSLT 1.0 where
variable references are prohibited inside a match pattern) and a set
of templates.

And modern refactoring concepts (such as the DRY principle) recommend
to eliminate conditional instructions by using polymorphism -- as what
I mention above for XSLT.

> debatable:
> xsl:value-of
> xsl:comment
> xsl:processing-instruction
> xsl:attribute
> xsl:element
> xsl:namespace-alias


Do you recommend not to be able to create *new* nodes -- elements,
attributes, comments, processing instructions, and namespace nodes, in
XSLT? This would be a serious cut of functionality. Or how these can
be expressed from the proposed kernel? I don't see any way to do this.


Cheers,
Dimitre

On Sat, Mar 29, 2014 at 9:51 AM, Abel Braaksma (Exselt) <abel@xxxxxxxxxx> wrote:
> (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):
>
> xsl:stylesheet/transform
> xsl:apply-templates
> xsl:call-template
> xsl:template
> xsl:if
> xsl:choose
> xsl:copy
> xsl:variable
> xsl:param
>
> debatable:
> xsl:value-of
> xsl:comment
> xsl:processing-instruction
> xsl:attribute
> xsl:element
> xsl:namespace-alias
>
> 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.
>
> Cheers,
>
> Abel Braaksma
> Exselt XSLT 3.0 processor
> http://exselt.net
>



-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
To achieve the impossible dream, try going to sleep.
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.


Current Thread
Keywords