Je sais que cette question est ancienne, mais entre toutes les réponses, je manque celle qui est une approche courante pour ce cas d'utilisation dans le développement XSLT.
J'imagine que le code manquant de l'OP ressemble à ceci:
<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>
Et que l'entrée ressemble à ceci:
<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>
C'est-à-dire que je suppose qu'il peut y avoir zéro, vide, un seul categoryName
élément ou plusieurs éléments. Traiter tous ces cas en utilisant xsl:choose
des constructions -style, ou en d'autres termes, impérativement, devient rapidement compliqué (encore plus si les éléments peuvent être à différents niveaux!). Un idiome de programmation typique dans XSLT utilise des modèles (d'où le T dans XSLT), qui est une programmation déclarative, pas impérative (vous ne dites pas au processeur quoi faire, vous dites simplement ce que vous voulez sortir si certaines conditions sont remplies). Pour ce cas d'utilisation, cela peut ressembler à ceci:
<!-- 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>
Cela fonctionne (avec n'importe quelle version XSLT), car la première ci-dessus a une priorité plus élevée (elle a un prédicat). Le modèle de correspondance "fall-through", le second, capture tout ce qui n'est pas valide. Le troisième se charge ensuite de sortir lecategoryName
valeur de manière appropriée.
Notez que dans ce scénario, il n'est pas nécessaire de faire correspondre spécifiquement categories
ou category
, car le processeur traitera automatiquement tous les enfants, sauf indication contraire (dans cet exemple, les deuxième et troisième modèles ne traitent pas davantage les enfants, car il n'y a pas xsl:apply-templates
dans leur).
Cette approche est plus facilement extensible que l'approche impérative, car elle traite automatiquement plusieurs catégories et peut être développée pour d'autres éléments ou exceptions en ajoutant simplement un autre modèle correspondant. Programmation sans if-branches .
Remarque: il n'y a rien de tel qu'en null
XML. Il existe xsi: nil , mais il est rarement utilisé, surtout rarement dans des scénarios non typés sans schéma d'aucune sorte.