Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] [XSL] Two "Philisophical" questions about the language
![[XSL] Two "Philisophical" questions about the language](/images/get_stylus.gif) 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]
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> </>
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
