Bonjour,
je pars de
<?xml version="1.0" encoding='UTF-8' ?>
<!DOCTYPE articles [
<!ENTITY suite SYSTEM "suite.xml">
]>
<articles>
<article>
<titre>le premier</titre>
</article>
&suite;
</articles>
Que doit-il y avoir dans suite.xml ?
J'ai essayé :
Ca dépend des navigateurs. Internet Explorer et Opera n'afficheront pas le contenu, mais afficheront les texte représentant l'entité, tandis que FireFox remplacera l'entité par le fichier. Du moins dans certains cas, parce que je l'ai testé, mais pas avec une entité (voir plus loin)....
De toute façon il y a erreur dans l'exemple que tu donne, parce que tu essaierai d'include un <articles> and un <articles>. Temps qu'il n'y a pas de validation du format du document, c'est Ok, mais pou un parser validant, c'est kO.
Ensuite, que souhaite tu faire ensuite avec le fichier XML ?
Dans l'esprit XML, si ton document fait référence à un autre document, alors il est plus judicieux d'avoir un modèle de document qui autorise les référence à d'autres document. Et alors par exemple si ensuite tu fais un traitement XSL, alors du pourra récupérer la référence, l'interpréter, et charger sa destination avec la fonction "document".
Exemple avec XSLT :
<xsl:applytemplates select="document('ma-reference-externe.xml')"/>
Il existe aussi d'autre moyen d'inclure un document XML dans un autre : c'est XInclude(IE et Opera ne font pas l'importation du document, tandis que FireFox le fait... question de choix, ça n'est pas une question de bug).
Personellement, si il doit y avoir interprétation, ma préférence va à un modèle de document ad-hoc qui permet des références à un document externes....
Merci pour la réponse.
En fait mon but est très simple c'est découper le fichier xml en plusieurs morceaux.
C'est une base d'articles, rangés par année.
J'ai an2007.xml, an2006.xml, etc... qui ne bougent plus.
Et un main.xml pour 2008 qui se remplit petit à petit.
J'écris main.xml comme ça
<?xml version="1.0" encoding='UTF-8' ?>
<!DOCTYPE articles [
<!ENTITY an2007 SYSTEM "an2007.xml">
<!ENTITY an2006 SYSTEM "an2006.xml">
]>
<articles>
<article>
<titre>le premier en 2008</titre>
</article>
<article>
<titre>le deuxième en 2008</titre>
</article>
...
&an2007;
&an2006;
...
</articles>
Comment doivent s'écrire an2007.xml et les autres, sachant qu'ils sont donc constitués des mêmes éléments
<article>
<titre>le premier en 2007</titre>
</article>
...
Comme je l'introduisais dans le précédent message, la solution a employé dépend de l'application finale qui sera faite du fichier, et surtout de l'application qui recevra les XML comme source.
Est-ce que ce sera un navigateur web ? Un processeur XSLT ? Etc, etc...
Dans ton cas, l'exemple que tu donne me fait diablement penser à un système de news (RSS peut-être ?). Si c'est bien un système de news, et que le fil RSS ou Atom est généré par une application quelconque, alors il n'est même pas nécéssaire de faire la moindre inclusion dans quelque fichier que ce soit. Si c'est une application PHP qui génère le file, tu la conçois de sorte à ce qu'elle soit capable d'aller chercher une série de fichier dans un repertoire, et à récupérer le(s) bon(s) en fonction de la date demandé comme point de départ pour le fil de news.
Je ne sais pas si c'est bien ça qu'il te faut, mais c'est au moins un exemple.
C'est vrai, je n'ai pas précisé l'usage.
En premier lieu c'est pour affichage par des navigateurs web (Firefox, IE, Opera,...) avec une appli PHP qui fait des tris selon certains critères sur les ATTRS des enregistrements par exemple.
Après ca sera si possible sur un fil RSS.
J'avais évidemment envisagé de faire lire par le PHP tous les fichiers xml, les parser et concaténer les tableaux en un seul. Mais je trouver l'idée de faire un seul xml plus élégante !
Si c'est plus compliqué, tant pis pour l'élégance, personne n'y verra rien !
Merci.
Il n'y a aucune raison de croire que ce ne serait pas élégant que d'accéder séparement à ces fichiers. D'ailleurs, tu peux tout à fait si tu le souhaite, créer un fichier XML qui serait un index de tous des fragment du document globale.
La question, comme tu le souligne, et de trouver un code permettant de demander aux navigateurs de combiner ensemble ces documents. Comme il n'existe pas de solution qui soit garantie d'être supportée par tous les navigateurs, la solution de faire prendre en charge cette combinaison par une application agissant derrière, est au contraire tout à fait élégante : on est bien tout à fait dans la logique client serveur ici En règle générale, le serveur tente de macher le travail au maximum pour le client, qui sera-lui, aussi léger que possible.