[xsl] [XSL] Two "Philisophical" questions about the language

Subject: [xsl] [XSL] Two "Philisophical" questions about the language
From: Alain <alainb06@xxxxxxx>
Date: Sat, 17 Jan 2009 12:23:02 +0100
Hi XSL experts,

I've always been wondering, and after a few hours of Googling found nothing about "philosophical" questions on the XSL language.

First one
--------------
We've got an instruction :
<xsl:if>

But this instruction has no <xsl:else> as any other language I've used.
I'm not saying <xsl:if> is useless, it IS: in case for example you want to add an attribute to a node on the result document under certain condition, but many times you have to use <xsl:choose> instead (when you can't replace it by a template) because you have an "else" part.
Of course you could write :
<xsl:if test="$condition">


then

<xsl:if test="not($condition)">

But that's quite bad for maintenance, and I assume not as optimized as could be an "else".
If coding with XSLT2.0, in some case you can also use a "workaround" through an XPATH test which allows an "else" part.


So my "philosophical" considerations are:
- If I had a pure "theoretical" view, we could do without <xsl:if>, you can just use <xsl:choose> instead and write the condition in a unique <xsl:case>. So, with this point of view, <xsl:if> can be discarded as a redundant keyword.
- If I had a "practical" view, <xsl:if> (when impossible to replace by a template) is useful to write shorter and more readable code. And should be even more useful with an <xsl:else> complement.


Then I don't understand the W3C position, as it is neither the "theoretical" one (no <xsl:if> at all) nore the practical one (add an <xsl:else>) ?
Could someone explain or give me pointers to discussions that leaded to this decision / trade-off ?


[Remark: if one is really starving to death to use <xsl:else> he can still have it! You just need to run a first transformation on the XSL code to transform <xsl:if><xsl:else> constructs to their equivalent with <xsl:choose><xsl:otherwise>, then you run the transformation with that new piece of code]




Second one ------------------ My second one might be easier!

Let's say I have an XML like this

<?xml version="1.0">
<root>
 <!-- Any number of nodes here -->
</root>

As a valid XML document can have only one "main" node, what is the architectural and practical difference between

<xsl:template select="/">

and

<xsl:template select="/root">

At the moment:
- they do the exact same thing
- the only difference is that the second one is less "generic" as it would select nothing if the name of my topmost node changes


The only useful distinction I can guess is that I would use the first construct if I had to make a very generic template that would have to run whatever node names are. In other cases, I feel safer to use the second one, although it's even better to use a schema to validate that the input XML is indeed what you expect it to be!

Is there ideas to "extend" XML and allow multiple topmost nodes ? In that case / would become the "unamed" topmost document node, and /some-node would be just one of the topmost. So, that would be equivalent to authorise an "unnamed" first node:

<?xml version="7.0">
<>
 <root1>
   <!-- Any number of nodes here -->
 </root1>
 <root2>
   <!-- Any number of nodes here -->
 </root2>
</>




Best Regards. Alain BENEDETTI

Current Thread