Intégration de multiples XHTML dans XML

Tout d'abord, bonjour à toute la communauté AlsacreationS, ça fait longtemps que je suis un visiteur régulier, mais aujourd'hui j'ai besoin d'aide... Désolé si la question a déja été posée, mais après moult recherches, je n'ai pas trouvé ce que je cherche...

Mon problème est le suivant: je crée actuellement un site internet basé sur du XML/XSLT, néanmoins, j'ai besoin d'incorporer du code XHTML dans mon fichier XML (je sais, il faut séparer le fond et la forme, mais le choix ne dépend pas de moi). La structure prend la forme suivante:

<root>
<title>Titre de la page</title>
<!--Un tas de balises prédéfinies qui n'ont pas d'importance et qui ne posent pas de difficultés...-->
.
.
.
<!--Ce qui suit concerne plus particulièrement ce qui m'intéresse...-->
<mws src="fichier01.html"/>
.
.
.
<!--Un autre tas de balises...-->
<mws src="fichier02.html"/>
.
.
.
<!-- Et ainsi de suite... -->

</root>

Voila dans les balises que j'appelle mws, je voudrais que la feuille XSL appelle les fichiers externes (qui sont en XHTML) et qu'elle interprète le code contenu dans ces fichiers HTML (attention cependant, ces fichiers HTML contiennent des balises dont on ne veut pas, i.e. la balise head), plus précisément le code contenu entre les balises body.

J'avais pensé à un apply-template brut, mais cela crée des conflits lorsque plusieurs balises mws sont appellées...

Quelqu'un peut-il m'aider pour ce problème?

D'avance merci...

bonsoir ,
je ne sais pas si l'tuilisation de Dom et javascript t'es 'permise dans cette application mais cette exemple peut t'aider ... enfin je l'espère !

Bonjour,

Le javascript est permis, mais il me semble important de détailler le processus de création du site, qui se passe en plusieurs étapes:
1. Je crée les données XML, et une feuille de style XSL unique qui couvre tous les besoins de mise en page (et un peu de CSS).
2. Via un script "Make" automatisé sous cygwin (interface linux sous windows), je demande à ce que tous les fichiers XML dans un répertoire donné soit passés à la moulinette (processeur XSLT), avec la feuille de style adéquate.
3. J'obtiens donc un tas de pages XHTML que j'uploade sur le serveur (ce n'est donc pas un site dynamique).

Je sais que ca risque d'en choquer quelques uns, mais le site est fait pour une application scientifique (ca veut dire que des chercheurs barbus et pas coiffés fonctionnant encore sous IE 5 vont aller voir le site ) donc on veut éviter à tout prix les requetes serveur (qui est très lent de surcroit), quant à la transformation XML/XSL côté client, mieux vaut oublier... (snif)).

Et je crois que je n'ai pas besoin de DOM ou JS, si on se base sur le schéma décrivant le processus de création:
http://img242.imageshack.us/img242/3797/processusir4.jpg

Voila j'espère que je suis assez clair, sinon n'hésitez pas à me demander de clarifier...

...

et avec la méthode document('lefichier.html') suivi d'une expression Xpath a partir de la racine du document (mais je ne suis pas sûr quel l'xtension ne doivent pas être obligatoirement fichier.xml .

document pointe en tout les cas la raicne du document "appelé" , et l'on peut donc utiliser une expression tel document(fichier.xml) /body ..

B on franchement je n'ai pas testé ( enfin plus exactement je cherche des solutions similaire pour les documents SVG, uniquement en Xml sans passé par un script JS ou un traitemetn script coté serveur ....tel php et les extensions Xml de traitement Dom très pratique ou bien l'utilisation de Exslt permettant d'inclure des fonctions php dirrrectement dans le code xslt ..)

Mais je pense que cette fonction document( ) pourrait etre une solution fiable , car elle permet dans une feuille Xslt générique d'intégrer différentes sources de données (aussi bien présente sur le sytème que distante ).
P rigaux en parle comme d'une 'bibliothéque de données" ... mais l'intégration ne se fait pas dans un fichier XML comme tu le proposes , mais lors du traitement lui même ..

enfin bon , c'est juste une idée et que j'essaie d'appliquer de mon coté sur des fichiers svg (donc Xml)

edit :
voici par exemple une transformation xslt a partir du fichier xml (plusieurs enfants 'item') qui appelle un doc svg ( ici toujours le même mais une simple condition xsl:if sur un attributs identifiant de l'item pourrait faire un conexte de condition ..)

<xsl:stylesheet  version="1.0" 
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"  
 xmlns:xlink="http://www.w3.org/1999/xlink"
 xmlns="http://www.w3.org/1999/xhtml">
 <xsl:output method="html"/>
 <xsl:template match="/">
 <html>
 <body>
 <xsl:apply-templates />
 </body>
 </html>
   
 </xsl:template>
 
 <xsl:template match="item">
  <xsl:apply-templates select="document('svg.xml')"/>
 </xsl:template>
 
 <xsl:template match="@*|node()">
  <xsl:copy>
   <xsl:apply-templates select="@*|node()"/>
   <xsl:text>application et appel du document svg pour autant</xsl:text>
   <xsl:text> d'item present dans les données de base
   </xsl:text>
  </xsl:copy>
 </xsl:template>
 
 </xsl:stylesheet>

résultat sur un navigatuer supportant le svg (ex: FF) et ayant un parseur Xml :
juste un petit test.
le traitement peut se faire en local avec Xalan par exemple ( a noter sur ce point des 'recherches pour la recommandation Xslt 2.0 par le W3C de nouvelle méthodes concernant les documents résultats avec par exemple 'xsl:result-document ' : voir extension Xalan open() , close() , write() ....
attention a bien préciser le nouvel espace de nom xmlns:redirect="org.apache.xalan.xslt.extensions.Redirect")
voilà , .. sicela peut t'aider un tant soit peu !!
Modifié par kzone (28 Jun 2007 - 10:22)

Bonjour,

kzone a écrit :
la méthode document('lefichier.html') suivi d'une expression Xpath a partir de la racine du document (mais je ne suis pas sûr quel l'xtension ne doivent pas être obligatoirement fichier.xml

Pas de contrainte sur le nom du fichier, en revanche le contenu doit évidemment être un contenu XML (donc la solution est la bonne pour B.O.R.E.T. si les fichiers sont bien du XHTML sans accroc).

kzone a écrit :
Mais je pense que cette fonction document( ) pourrait etre une solution fiable

oui bien sur que ça marche.

Merci beaucoup pour tout ces conseils, mais il me reste un petit problème: est-il possible de créer un template à partir d'un arbre provenant d'un doc externe??

En effet, j'ai par exemple créé un menu (dropdown type JS inspiré d'un des tutos de ce site), qui utilise un fichier .xml pour organiser le contenu des menus et catégories, et dans le .xsl, le code ressemble à ceci:

<div id="topmenu">
<xsl:apply-templates select="document('topmenu.xml')/topmenu"/>
</div>

Et le template ressemble à ceci:

<xsl:template match="topmenu">
	<ul>
	<xsl:for-each select="cat">
	<xsl:choose>
	<xsl:when test="./@href">
	<li>
	<a>
	<xsl:attribute name="href">
<xsl:value-of select="./@href"/>
</xsl:attribute>
<xsl:value-of select="./@name"/>
</a>
</li>
</xsl:when>
	<xsl:otherwise>
	<li>
	<a href="#">
<xsl:value-of select="./@name"/>
</a>
	<ul>
	<xsl:for-each select="link">
	<li>
	<a>
	<xsl:attribute name="href">
<xsl:value-of select="./@href"/>
</xsl:attribute>
<xsl:value-of select="./@name"/>
</a>
</li>
</xsl:for-each>
</ul>
</li>
</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
</ul>
</xsl:template>

La où je voudrais attirer votre attention, c'est que le nommage du template n'est pas du type document('topmenu.xml')/topmenu (topmenu étant le noeud racine du fichier externe), mais topmenu tout court... (<xsl:template match="topmenu">)

Ce qui est une solution valable si on considère que topmenu sera une balise réservée. Seulement, dans des fichiers XHTML, les balises en question ne sont pas uniques, on retrouvera la même structure <html>...<head>...<body> partout...

Or, on ne pourra créer qu'un seul template, qui du coup s'appelera html/body, et j'ai peur que cela crée des conflits si plusieurs fichiers XHTML sont appelés... Qu'en pensez vous???

B.O.R.E.T. a écrit :
est-il possible de créer un template à partir d'un arbre provenant d'un doc externe??

Cette formulation est ambiguë. Un template "provient" de nul part. Il existe dans l'absolue. En revanche il s'applique à quelque chose, et ce quelque chose peut avoir une provenance variée.
Il faut bien garder en tête le principe fondé sur les 3 notions :
- XML source
- XML résultat
- transformation
Un template appartient à la transformation. On décidera de l'appliquer à des éléments du XML source, et l'on obtiendra un résultat.

=B.O.R.E.T. a écrit :
Or, on ne pourra créer qu'un seul template, qui du coup s'appelera html/body, et j'ai peur que cela crée des conflits si plusieurs fichiers XHTML sont appelés... Qu'en pensez vous???

Je n'en pense que du bien. C'est très classique et c'est fait pour. Plus un template est générique, mieux c'est. Ensuite c'est toi qui décides ce sur quoi tu l'appliques.

kzone a écrit :
Quand je regarde ton schéma je me pose la question : comment seront généré tes fichiers (X) html joint , car s'ils proviennent de sources diverses (externes ou internes) sur lesquelles vous n'etes pas responsable de leur écriture , comment être sur de leur conformité au langage Xml avant de les insérer dans le fichier générique Xml .. une moindre erreur dans le 'fichier joint' au niveau du respect des règles de document XMl entrainera automatiquement une erreur de parseur sur tout le document ...

Je me suis déja posé la question, et j'ai trouvé la réponse:

Pour ce faire, je prie régulièrement et j'ai allumé quelques cierges que j'ai soigneusement disposés autour de mon PC ... Les fichiers (X?)HTML proviennent de feuilles de travail Maple converties, et après plusieurs essais fructueux, et si on regarde le DOCTYPE, je pense que je peut faire confiance à ces fichiers.

Plus sérieusement, la question que je me posais était la suivante: imaginons que je fasse appel à plusieurs fichiers XHTML externes, qui ont tous la même structure (ce qui est assez normal...), et puis je dis dans mon XML/ xsl=>

CODE XML:
<root>
<blabla....>
<mws src="fichier01.html"/>
<reblabla....>
<mws src="fichier02.html"/>
</root>

<!---------------------------------------------------------------->
CODE XSL:

<xsl:apply-templates select="root"/>
<!--QUESTION N°1: sachant que dans mon XML j'ai demandé à ce que 2 fichiers externes soient appelés, est on sur que les 2 codes contenus dans les fichiers respectifs seront tous 2 interprétés et non pas uniquement le 2eme ou le 1er (notion de conflit)?-->
...

<xsl:template match="root/blabla">
...
<!--On définit tous les templates enfants à root, comme ca on peut faire un apply-template de root directement, ce qui permet de respecter la chronologie du document...-->

<xsl:template match="root/mws">
<!--QUESTION N°2: Qu'est ce que je peux bien mettre ici??? Sachant que le code contenu dans chacun des fichiers est différent (mais de type XML)-->

Et pour répondre à Xavier, je recherche exactement le template le plus générique qui soit, le seul problème, c'est la multiplicité des sources externes qui servent à générer le document final. Ce que je voulais dire en parlant de template "externe" c'est une expression du type <xsl:template match="document('fichier.html')/..."/>, mais les processeurs XSLT (en tout cas le mien) ne semblent pas apprécier... Bref cela ne fonctionne pas...

a écrit :
Et pour répondre à Xavier, je recherche exactement le template le plus générique qui soit, le seul problème, c'est la multiplicité des sources externes qui servent à générer le document final. Ce que je voulais dire en parlant de template "externe" c'est une expression du type <xsl:template match="document('fichier.html')/..."/>, mais les processeurs XSLT (en tout cas le mien) ne semblent pas apprécier... Bref cela ne fonctionne pas...

Oui, non, ça ne marche pas comme ça. D'ailleurs ton template n'est pas générique du tout puisqu'il voudrait être spécifique au fichier.html. Tu ne vas quand même pas écrire autant de templates que de fichiers externes, de toute façon ça n'est pas autorisé.

Comme kzone a donné la solution au dessus j'ai pensé que c'était suffisant :
1/ template générique,
2/ appel du template sur les éléments sources qui conviennent et c'est là que tu utilises la fonction document().
Modifié par Xavier (29 Jun 2007 - 15:21)

je reviens juste sur l'utilisation de la fonction document pour un article
sur Xml.com : Reading Multiple Input Documents.

++