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

["Abel Braaksma (Exselt)" <abel@xxxxxxxxxx>]

On 29-3-2014 18:44, Dimitre Novatchev wrote:
> First a general remark:
>
>   It is well-known that the modern Number theory can be entirely
> expressed using only the seven Peano axioms. 

I'll have to look that up to be able to make that "well-known" to me too ;).

> 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.

My attempt was given into by recent discussions on small parts of the
language, that focused on details. I think it helps us in distinguising
the details from the big picture, or the core from extensions (even
though in the case of XSLT, we currently do not have such distinction).

In a more dream-like manner, it may ultimately lead to splitting the
spec in Core, Extensions, Streaming, or something like that, though I'm
drifting ;).

>> 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.

Agreed, but when working with non-nodes, like atomic values, we cannot
apply-templates on them. This limitation has been lifted in XSLT 3.0, in
which case apply-templates probably suffices.

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

Unfortunately, XSLT does not have a notion of polymorphism. But that
does not mean DRY does not apply.

>> 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.

No. The point is that with xsl:value-of and disable-output-escaping you
have an assembly-style instruction that can create all the other node
kinds. Conversely, one could argue that d-o-e is itself a non-essential
extension to the language. Still, xsl:element is not required because
you can use LRE's, but I think there are scenarios that are hard or
impossible to express without xsl:attribute, as we cannot use LRE's to
just express an attribute declaration, there already has to be an LRE of
an element as well.

To summarize, options:
1) xsl:value-of could be enough for all
2) xsl:value-of can removed, as you can use string() and concat() with
xsl:copy
3) xsl:element can be removed in favor or LRE's
4) we leave them all in

Anything else I missed in the Core?

Cheers,

Abel Braaksma
Exselt XSLT 3.0 processor
http://exselt.net