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 categoryName
elementi. Affrontare tutti questi casi usando xsl:choose
costrutti 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 categoryName
valore in modo corretto.
Si noti che in questo scenario non v'è alcuna necessità di specifially abbinare categories
o 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-templates
in 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 null
in XML. C'è xsi: nil , ma è usato raramente, specialmente raramente in scenari non tipizzati senza uno schema di qualche tipo.