Discussion :

[yacc22]

Bonjour,
je voudrais pouvoir générer une élément XML dont la balise de début <monElt> serait générée dans un template, et la balise de fin dans un autre template.

Par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
<?xml version="1.0"?>
<?mso-application progid="Excel.Sheet"?>
<!-- xsl tag  START -->
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes" encoding="utf-8"/>
<xsl:strip-space elements="*"/>
<xsl:template match="/">
   <xsl:apply-templates select="/myNode" mode="Debut" />
   .... traitements
   <xsl:apply-templates select="/myNode" mode="Fin" />
</xsl:template>
 
<xsl:template match="myNode" mode="Debut">
   <monElt>
</xsl:template>
<xsl:template match="myNode" mode="Fin">
   </monElt>
</xsl:template>

Malheureusement le processeur XSLT génère deux erreurs equivalentes, une dans chaque template.
Par exemple, pour le premier template :

Le balise de fin xsl:template ne correspond pas à la balise de début monElt

Le processeur XSLT semble considérer que la définition de template doit etre bien formée d'un point de vue XML.

Je ne peux pas utiliser l'élément <xsl:element> pour generer l'element monElt
car en resultat de <xsl:element> les deux balises debut et fin sont générées, empéchant d'insérer du texte.

Y a-t-il un moyen en XSL d'ajouter en deux étapes différentes les deux balises début et fin d'un element XML de sortie?

Merci d'avance pour votre aide

[yacc22]

Pour info j'ai trouvé une solution qui fonctionne bien avec MSXML.

Il suffit d'utiliser l'élément xsl:text avec l'attribut disable-output-escaping="yes" et d'encoder les caractères < et > délimitant la balise :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
......
<xsl:template match="myNode" mode="Debut">
<!-- au lieu d'écrire directement <monElt> qui n'a pas la balise </monElt> dans 
       le même scope, on utilise l'élément xsl:text -->
<!-- dans cet exemple, monElt contient un attribut name de valeur yacc
  <xsl:text disable-output-escaping="yes">
    &lt;monElt name="yacc" &gt;
  </xsl:text>
</xsl:template>
<xsl:template match="myNode" mode="Fin">
<!-- même solution que pour le template ci-dessus pour la balise de fin -->
  <xsl:text disable-output-escaping="yes">
    &lt;/monElt&gt;
  </xsl:text>
</xsl:template>

Problème non résolu, mais dans mon cas je ne le rencontre pas, : cas où dans l'élément à définir, il y a des attributs dont la valeur contient le caractère &. Son codage par &amp; semble ne pas être correctement interprété

[alain.couthures]

C'est vraiment un principe de XSL-T que d'avoir une feuille de style qui est elle-même un document XML bien formé.

Quand on débute avec XSL-T, on prend cela pour une restriction mais, à l'usage, on s'aperçois que c'est une autre façon de concevoir ses traitements que je qualifierais de "logique" : XSL-T ne s'utilise pas comme un L3G, il faut toujours réfléchir (c'est parfois prise de tête...) plutôt que "pisser du code" .

Je serais très étonné que votre problème ne trouve pas de solution XSL-T "propre".

[yacc22]

J'utilise XSL-T pour créer un document EXCEL 2003 : le XSL de départ est le XML produit par EXCEL, sur un document"modèle" avec des cellules "tagées" pour pouvoir les retrouver dans le XSL.

Mon problème est qu'en fonction des données d'entrée, disponibles également en XML, certaines parties du document EXCEL doivent disparaitre/apparaître (le document eXCEL de sortie est en quelque sorte dynamique) Et comme la position des ces parties (par exemple des cellules dans une ligne) n'est pas connue d'avance, il est beaucoup plus facile d'utiliser une approche récursive, où un template XSL peut être amené à construire une partie "mal-formée" du XML de sortie.

Mais là, j'en conviens, c'est une approche de programmeur!

Je suis d'accord, avec une approche "en extension", où un template existerait pour chaque structure XML valide et modifiable du document EXCEL de sortie, je pourrai aboutir à un XSL bien formé. Mais ceci au prix d'un volume de texte XSL sans commune mesure beaucoup plus important que ce que je dois gérer actuellement.