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

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

---

---

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   -->
  </xsl:template>


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

---