- From: Jim Melton <jim.melton@acm.org>
- Date: Fri, 02 Apr 2004 11:38:59 -0700
- To: Dimitre Novatchev <dnovatchev@yahoo.com>
- Cc: Oliver Becker <obecker@informatik.hu-berlin.de>, public-qt-comments@w3.org
Dimitre, At 07:34 AM 4/2/2004 Friday, Dimitre Novatchev wrote: >Oliver, > >Why support a redundant costruct, when using xsl:choose is already there >and is much more cleaner in specifying the scope in which any xsl:when or >xsl:otherwise must occur? First, let me say that I agree with Oliver that it wouldn't be difficult to have syntax that avoids the dangling-else problem. In addition, there are many languages that resolve the dangling-else by means of clear, easy-to-remember rules. Second, with regard to "why not use xsl:choose", I have to admit that I start off writing the content of a template quite often with an xsl:if, thinking that I only need to do something if the test succeeds and do nothing if it fails. Shortly after writing this, I suddenly realize that I do need to something if the test fails, so I am forced to restructure my code in a slightly inconvenient way to replace what could have been simple if...then...else with a choose...when...otherwise.../choose. Of course, having to do that is not a disaster, but it is inconvenient and annoying. In most (but not all) programming languages that I have used, one naturally selects an if/then/else construct for binary decisions and a choose-type construct for decisions that have more than 2 branches. Besides, there was no reason to be so hostile to the submitter of the original question. It seemed rude to just keep informing him that he's just too dumb to realize that the "right" decision was already made and he shouldn't be questioned such received wisdom. Feeling grumpy, Jim >This is clearly not to occupy space on this list -- I agree. At least for >such simple questions, for which anyone can find the answer if they think. > >Regards, >Dimitre. > > > > Dimitre, > > > > since the W3C doesn't want to add xsl:else, this discussion might be > > pointless. However: requiring that xsl:else must always follow > > immediately > > an xsl:if is IMHO not more complicate than requiring that xsl:param must > > always come first within a template. > > > > Moreover, there is no dangling else here: > > > > if x then (if y then a else b) > > becomes > > <xsl:if test="x"> > > <xsl:if test="y">a</xsl:if> > > <xsl:else>b</xsl:else> > > </xsl:if> > > > > if x then (if y then a) else b > > becomes > > <xsl:if test="x"> > > <xsl:if test="y">a</xsl:if> > > </xsl:if> > > <xsl:else>b</xsl:else> > > > > Regards, > > Oliver Becker > > >__________________________________ >Do you Yahoo!? >Yahoo! Small Business $15K Web Design Giveaway >http://promotions.yahoo.com/design_giveaway/ ======================================================================== Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone: +1.801.942.0144 Oracle Corporation Oracle Email: jim dot melton at oracle dot com 1930 Viscounti Drive Standards email: jim dot melton at acm dot org Sandy, UT 84093-1063 Personal email: jim at melton dot name USA Fax : +1.801.942.3345 ======================================================================== = Facts are facts. However, any opinions expressed are the opinions = = only of myself and may or may not reflect the opinions of anybody = = else with whom I may or may not have discussed the issues at hand. = ========================================================================
Received on Friday, 2 April 2004 14:56:37 UTC