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 12:00:52 -0700
On Sat, Mar 29, 2014 at 11:21 AM, Abel Braaksma (Exselt)
<abel@xxxxxxxxxx> wrote:
> 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
>>> 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.

I meant:

   <xsl:apply templates select="my:specialNode[condition-here]"/>

  .   .   .   .   .   .   .   .

  <xsl:template match="my:specialNode">

     <!-- Whatever needs to be done   -->

Where did I say that we need to apply templates on non-nodes?

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

This is not true -- elements and attributes with dynamically
determined name cannot be generated using LRE.
Same for namespace nodes with dynamically determined namespace-uri

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

See above

> 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

Not reflecting the reality. LREs don't cover the dynamic case

> 4) we leave them all in
> Anything else I missed in the Core?
> Cheers,
> Abel Braaksma
> Exselt XSLT 3.0 processor

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