So che questa domanda è vecchia, ma tra tutte le risposte, mi manca una che è un approccio comune per questo caso d'uso nello sviluppo di XSLT.
Immagino che il codice mancante dall'OP assomigli a questo:
<xsl:template match="category">
<xsl:choose>
<xsl:when test="categoryName !=null">
<xsl:value-of select="categoryName " />
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="other" />
</xsl:otherwise>
</xsl:choose>
</category>
E che l'input è simile al seguente:
<categories>
<category>
<categoryName>Books</categoryName>
</category>
<category>
<categoryName>Magazines</categoryName>
<categoryName>Periodicals</categoryName>
<categoryName>Journals</categoryName>
</category>
<category>
<categoryName><!-- please fill in category --></categoryName>
</category>
<category>
<categoryName />
</category>
<category />
</categories>
Cioè, suppongo che ci possano essere zero, vuoti, singoli o multipli categoryNameelementi. Affrontare tutti questi casi usando xsl:choosecostrutti in stile, o in altre parole, in modo imperativo, sta rapidamente diventando confuso (ancora di più se gli elementi possono essere a livelli diversi!). Un tipico linguaggio di programmazione in XSLT sta usando i template (da qui la T in XSLT), che è programmazione dichiarativa, non imperativa (non dite al processore cosa fare, dite semplicemente cosa volete output se sono soddisfatte determinate condizioni). Per questo caso d'uso, potrebbe essere simile al seguente:
<!-- positive test, any category with a valid categoryName -->
<xsl:template match="category[categoryName[text()]]">
<xsl:apply-templates />
</xsl:template>
<!-- any other category (without categoryName, "null", with comments etc) -->
<xsl:template match="category">
<xsl:text>Category: Other</xsl:text>
</xsl:template>
<!-- matching the categoryName itself for easy handling of multiple names -->
<xsl:template match="categoryName">
<xsl:text>Category: </xsl:text>
<xsl:value-of select="." />
</xsl:template>
Funziona (con qualsiasi versione XSLT), perché la prima sopra ha una precedenza più alta (ha un predicato). Il modello di corrispondenza "fall-through", il secondo, rileva tutto ciò che non è valido. Il terzo si occupa quindi di fornire il categoryNamevalore in modo corretto.
Si noti che in questo scenario non v'è alcuna necessità di specifially abbinare categorieso category, perché il processore elabora automaticamente tutti i bambini, a meno che non diciamo altrimenti (in questo esempio, il secondo e il terzo modello NON ulteriore processo i bambini, perché non c'è xsl:apply-templatesin loro).
Questo approccio è più facilmente estendibile di quello imperativo, perché si occupa automaticamente di più categorie e può essere espanso per altri elementi o eccezioni semplicemente aggiungendo un altro modello di corrispondenza. Programmazione senza if-branch .
Nota: non esiste qualcosa come nullin XML. C'è xsi: nil , ma è usato raramente, specialmente raramente in scenari non tipizzati senza uno schema di qualche tipo.