"G. Ken Holman" wrote:

> I'd like to see the use of <xsl:otherwise> as an "else" in the <xsl:if>
> test construct:
>
>     <xsl:if test="">
>       ...
>       <xsl:otherwise>
>         ...
>       </xsl:otherwise>
>     </xsl:if>
>
> As well, a backward incompatible change would be to rename <xsl:otherwise>
> to <xsl:else>, then we would have:
>
>     <xsl:choose>
>       <xsl:when test="">
>         ...
>       </xsl:when>
>       <xsl:when test="">
>         ...
>       </xsl:when>
>       <xsl:when test="">
>         ...
>       </xsl:when>
>       <xsl:else>
>         ...
>       </xsl:else>
>     </xsl:choose>
>
>   and
>
>     <xsl:if test="">
>       ...
>       <xsl:otherwise>
>         ...
>       </xsl:otherwise>
>     </xsl:if>
>
> Alternatively (no pun intended), perhaps just remove the existing <xsl:if>
> construct entirely and force people to use <xsl:choose>, substituting the
> existing "when" with "if":
>
>     <xsl:choose>
>       <xsl:if test="">
>         ...
>       </xsl:if>
>       <xsl:if test="">
>         ...
>       </xsl:if>
>       <xsl:if test="">
>         ...
>       </xsl:if>
>       <xsl:else>
>         ...
>       </xsl:else>
>     </xsl:choose>

Forget about being backwards compatible as XSL is still a working draft.
Nonetheless, this is a great idea.  You would not have to wrap everything in a
choose element if you did something like:

<xsl:if test="">
</xsl:if>
<xsl:else-if test="">
</xsl:else-if>
<xsl:else>
</xsl:else>

Not sure how to represent this in a DTD, but I think it would be more natural
to most programmers.  Even if you leave xsl:choose around, it would sure be
convenient for xsl:if to at least have a fallback processing element like the
suggested xsl:else.

Tyler


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list