🚀 go-pugleaf

Eric Jacoboni <jaco@titine.fr.eu.org> writes:

> 
> soit la balise <url> d�finie dans ma DTD et utilisable ainsi :
> 
> <url nom="Ce fichier" lien="http://www.machin.org/fichier">
> 
> je veux qu'elle soit traduite en HTML ainsi :
> 
> <a href="http://www.machin.org/fichier">Ce fichier</a>
> 
> et je n'y arrive pas avec xls. � tout hasard (on peut r�ver...) j'ai
> essay� :
> 
> <xls:template match="url">
>   <a href=<xls:value-of select="@lien">>
>   <xls:value-of select="@nom"></a>
> </xls:template>

<xsl:template match="url">
  <a href="{@lien}"><xsl:value-of select="@nom"/></a>
</xsl:template>

> 
> mais je me fais jeter grave ;-)
> 
> Il y a t-il donc un moyen de r�gler �a ?
> 
> La question se posera �galement pour ma balise <LISTE> qui admet un
> param�tre facultatif, 'type' pouvant valoir "simple" (le d�faut) et
> "enum". Pour produire le HTML correspondant, il faudra bien que
> j'effectue un test sur cette valeur pour produire soir un <UL> soit un
> <OL>...

Pour tester si un �l�ment existe :
<xsl:if test="liste">
  ...
</xsl:if>

ou l'autre variante :
<xsl:choose>
  <xsl:when test="liste">
    ...
  </xsl:when>
  ...
</xsl:choose>

> 
> Autre question subsidiaire : quel est l'int�r�t du
> xmlns:xsl='http://www.w3.org/1999/XSL/Transform' que l'on est oblig�
> de mettre dans l'ent�te, vu que je fais tout moi-m�me ?

C'est la d�finition du namespace (le xsl: devant les commandes)
(note c'est bien xsl et non xls)

> 
> <interrogation mode="naif"> 
> 
> Et, euh, si j'osais... : quel est l'int�r�t de XSL quand on sait
> qu'avec Expat (ou assimil�) on peut faire la m�me chose sans devoir
> apprendre une nouvelle syntaxe ? Je veux dire par l� que l'exemple de
> ma balise <url> se r�glait en Perl en trois coup de cuill�re � pot :

Avec XSL tu peux faire la transformation � la vol�e :
- Soit sur le serveur Web (par exemple avec Cocoon) tu inclue un
stylesheet dans ton fichier XML et ton fichier s'affichera sous forme
HTML (ou autre). Voici un exemple :
<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<?xml-stylesheet type="text/xsl" href="index.xsl"?>
<?cocoon-process type="xslt"?>

- Soit sur le client, et dans ce cas le serveur envoie du XML et
chaque client fait la transformation ad�quate (HTML pour Netscape,
texte pour un browser texte, WML pour un client WAP ...)


> 
> sub url {
>     my ($p, $balise, %attribs) = @_;
>     print "<a href=$attribs{'lien'}>$attribs{'nom'}"; 
> }
> 
> sub url_ {
>     print "</a>";
> }
> 
> idem pour <liste>...
> 
> </interrogation>
> 
> 
> -- 
> ---------------------------------------------------------
> �ric Jacoboni       � No sport, cigars! �  (W. Churchill)
> ---------------------------------------------------------

-- 
I am not listed on the United States Department of Treasury lists of
Specially Designated Nationals, Specially Designated Terrorists, and
Specially Designated Narcotic Traffickers, nor am I listed on the
United States Department of Commerce Table of Denial Orders. 

On Fri, 25 Aug 2000, jaco@titine.fr.eu.org wrote:

> J'ai r�cup�r� une tonne de docs, moult exemples, mais pas moyen de
> comprendre comment faire la m�me chose qu'une bonne vieille
> interpolation � la Perl :
> 
> soit la balise <url> d�finie dans ma DTD et utilisable ainsi :
> 
> <url nom="Ce fichier" lien="http://www.machin.org/fichier">
> 
> je veux qu'elle soit traduite en HTML ainsi :
> 
> <a href="http://www.machin.org/fichier">Ce fichier</a>
> 
> et je n'y arrive pas avec xls. � tout hasard (on peut r�ver...) j'ai
> essay� :
> 
> <xls:template match="url">
>   <a href=<xls:value-of select="@lien">>
>   <xls:value-of select="@nom"></a>
> </xls:template>

Il faut tout dire explicitement (et �crire xsl au lieu de xls, et fermer
ses �l�ments vides) :

<xsl:template match="url">
 <a><!-- ou <xsl:element name="a">, ce qui permettrait de cr�er des
         �l�ments calcul�s -->
  <xsl:attribute name="href"><!-- Le nom de l'attribut pourrait �tre
                                  calcul� et non constant -->
     <xsl:value-of select="@lien"/>
  <xsl:attribute/>
  <xsl:value-of select="@nom"/>
 </a>
<xsl:template/>

En tout cas, inutile d'essayer d'imbriquer un �l�ment dans un autre :
ton script XSLT doit rester du XML.

> La question se posera �galement pour ma balise <LISTE> qui admet un
> param�tre facultatif, 'type' pouvant valoir "simple" (le d�faut) et
> "enum". Pour produire le HTML correspondant, il faudra bien que
> j'effectue un test sur cette valeur pour produire soir un <UL> soit un
> <OL>...

Laiss� en exercice :-)

> Autre question subsidiaire : quel est l'int�r�t du
> xmlns:xsl='http://www.w3.org/1999/XSL/Transform' que l'on est oblig� de
> mettre dans l'ent�te, vu que je fais tout moi-m�me ?

Espace de noms. Si MS veut faire son XSL perso, au moins on saura qu'il
n'est pas standard.
 
> <interrogation mode="naif"> 
> 
> Et, euh, si j'osais... : quel est l'int�r�t de XSL quand on sait
> qu'avec Expat (ou assimil�) on peut faire la m�me chose sans devoir
> apprendre une nouvelle syntaxe ? Je veux dire par l� que l'exemple de
> ma balise <url> se r�glait en Perl en trois coup de cuill�re � pot :
> 
> sub url {
>     my ($p, $balise, %attribs) = @_;
>     print "<a href=$attribs{'lien'}>$attribs{'nom'}"; 
> }
> 
> sub url_ {
>     print "</a>";
> }
> 
> idem pour <liste>...
> 
> </interrogation>

XPATH me semble sup�rieur quand on doit aller r�cup�rer des donn�es dans
les profondeurs d'une for�t de documents, pour les combiner avec d'autres,
encore plus �loign�es. Dans l'exemple ci-dessous, imagine que tu aies �
faire au deuxi�me petit fils du grand-p�re de <url>. Cela dit, XML::XPath
est pratiquement termin� :-)

X.

>>>>> "XC" == Xavier Cazin <cazinx@online.fr> writes:


XC> Il faut tout dire explicitement (et �crire xsl au lieu de xls, et fermer
XC> ses �l�ments vides) :

Euh oui, my fault, j'ai tap� un peu vite mais mon .xls contenait bien
des xsl: sinon Sablotron m'aurait jet� avant...


XC> En tout cas, inutile d'essayer d'imbriquer un �l�ment dans un autre :
XC> ton script XSLT doit rester du XML.

D�formation professionnelle...

XC> Laiss� en exercice :-)

Merci ;-) Qui ne tente rien n'a rien...


XC> Dans l'exemple ci-dessous, imagine que tu aies �
XC> faire au deuxi�me petit fils du grand-p�re de <url>. 

Je me refuse � consid�rer cette �ventualit�... Sinon, il faudra aussi
que je prenne en compte le crash de mon disque dur.

Cela dit :

% cat testurl.xml
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!DOCTYPE article SYSTEM "article.dtd" []>

<article titre="Test url">
  <tete>
    <version>0.1</version>
    <date>25 ao�t 2000</date>
    <auteur>�ric Jacoboni</auteur>
   </tete>

  <corps> 
   <url nom="Premi�re" lien="http://machin.org/premiere">
      Premi�re
      <url nom="Seconde" lien="http://machin.org/seconde">
        Seconde
        <url nom="Troisi�me" lien="http://machin.org/troisi�me">
        Troisi�me
        </url>
      </url>
   </url>
  </corps>
</article>

% ./xml2html testurl.xml
<html>
  <head>
<title>Test url</title>
</head>
<body bgcolor="#ffffff">
<center><h1>Test url</h1></center>
<hr>

    Version : <tt>0.1</tt><br>
    Date    : <em>25 ao�t 2000</em><br>
    Auteur  : <em>�ric Jacoboni</em><br>

   <a href=http://machin.org/premiere>Premi�re
      Premi�re
      <a href=http://machin.org/seconde>Seconde
        Seconde
        <a href=http://machin.org/troisi�me>Troisi�me
        Troisi�me
        </a>
      </a>
</a>
  </body>
</html>

Cela reste donc coh�rent au niveau HTML (quant � savoir � quoi cela
peut bien servir...)

XC> Cela dit, XML::XPath
XC> est pratiquement termin� :-)

Je viens de recevoir la lettre d'info Perl-News indiquant que
XML-XPath-0.98 est dispo...

En tous cas, merci � toi et � Doeni pour l'info sur la transformation
xls de <url>
-- 
---------------------------------------------------------
�ric Jacoboni       � No sport, cigars! �  (W. Churchill)
---------------------------------------------------------

Eric Jacoboni <jaco@titine.fr.eu.org> a �crit dans le message :
87d7ixgl96.fsf@titine.fr.eu.org...
> <interrogation mode="naif">
>
> Et, euh, si j'osais... : quel est l'int�r�t de XSL quand on sait
> qu'avec Expat (ou assimil�) on peut faire la m�me chose sans devoir
> apprendre une nouvelle syntaxe ? Je veux dire par l� que l'exemple de
> ma balise <url> se r�glait en Perl en trois coup de cuill�re � pot :
>
> sub url {
>     my ($p, $balise, %attribs) = @_;
>     print "<a href=$attribs{'lien'}>$attribs{'nom'}";
> }
>
> sub url_ {
>     print "</a>";
> }
>
> idem pour <liste>...
>
> </interrogation>

Tu n'as pas � t'occuper du processeur XSLT qu'auront les "lecteurs"
eventuels de tes documents (si tu les distribuent ensemble).
Bien s�r si tu les garde pour toi (ou au moins la partie transformation),
XSLT ne te sert pas � grand chose.

XSLT est plus puissant qu'un processeur SAX comme Expat qui ne te permet pas
(ou en tous cas pas facilement) de r�ordonner tes �l�ments par exemple.
J'avais un probl�me tout b�te :
passer de (en gros) :
<page>
  <section>
    <titre>Titre 1</titre>
    <texte>bla bla bla 1</texte>
  </section>
  <section>
    <titre>Titre 2</titre>
    <texte>bla bla bla 2</texte>
  </section>
  etc.
</page>
�
<table summary="Titre 1"><tr>
<th>Titre 1</th>
<td>bla bla bla 1</td>
</tr></table>
<table summary="Titre 2"><tr>
<td>bla bla bla 2</td>
<th>Titre 2</td>
</tr></table>
etc.

En r�sum�, inverser titre et texte une fois sur 2 (mais garder le titre dans
le summary) . Avec expat (utilis� avec PHP pour ma part ;o) , pas facile et
surtout peu lisible, avec XSLT c'est un jeu d'enfant.

XSLT donne aussi d�j� en partie une vision du r�sultat final, avec expat tu
as �t� oblig� de s�parer ton <a> du </a> , ca devient vite illisible et peu
maintenable.

Ces propos n'engagent que moi comme toujours.

PS: ah, discuter avec "Jaco", celui qu'on a tant admir� quand on d�butait
avec sa Linuxette, son sendmail, son inn, les SGBD, etc. et duquel on
profite toujours des articles ! Alors j'en profite pour te lancer un grand
MERCI ;o)
--
Voili voilou

(TOM)

>>>>> "(TOM)" == (TOM)  <ptittom@free.fr> writes:

(TOM)> Tu n'as pas � t'occuper du processeur XSLT qu'auront les "lecteurs"
(TOM)> eventuels de tes documents (si tu les distribuent ensemble).

Oui, vu sous cet angle... Moi je partais du principe que :

1) tout syst�me s�rieux � Perl
2) j'envoyais le doc XML + la DTD + les scripts de transformation
3) il suffit au lecteur d'installer XML::Parser en trois coups de
   cuill�re a pot (un appel � make), il a le html, le tex, le docbook.

(TOM)> XSLT est plus puissant qu'un processeur SAX comme Expat 

Peut-�tre, je ne connais pas suffisamment pour juger, je parlais du
point de vue qui est le mien : je ma�trise suffisamment bien la
programmation pour que la confection de scripts ne me pose pas de
probl�me. D'o� la question sur l'int�r�t d'apprendre un autre
langage. Je pense que le r�el atout de xls est, comme le dit Doeni,
est sa facult� de g�n�ration � � la vol�e �.

(TOM)> Avec expat (utilis� avec PHP pour ma part ;o) , pas facile et
(TOM)> surtout peu lisible, avec XSLT c'est un jeu d'enfant.

Mouais, il suffisait de d�clarer une variable pour m�moriser le titre
de la section en cours, non ? Dans le m�me ordre d'id�e, g�n�rer une
table des mati�res dans la transformation HTML est facile avec Expat,
je tremble � l'id�e de le faire avec XSLT...

(TOM)> PS: ah, discuter avec "Jaco"

You're welcome ;-)

-- 
---------------------------------------------------------
�ric Jacoboni       � No sport, cigars! �  (W. Churchill)
---------------------------------------------------------

>>>>> "Doeni" == Doeni  <doeni@evhr.net> writes:


>> La question se posera �galement pour ma balise <LISTE> qui admet un
>> param�tre facultatif, 'type' pouvant valoir "simple" (le d�faut) et
>> "enum". Pour produire le HTML correspondant, il faudra bien que
>> j'effectue un test sur cette valeur pour produire soir un <UL> soit un
>> <OL>...


Doeni> ou l'autre variante :
Doeni> <xsl:choose>
Doeni>   <xsl:when test="liste">
Doeni>     ...
Doeni>   </xsl:when>
Doeni>   ...
Doeni> </xsl:choose>

Merci, comme disait Xavier, j'ai fait mon exercice et je le soumet �
votre sagacit� :

<xsl:template match="liste">
  <xsl:choose>
    <xsl:when test="@type='enum'">
      <ol><xsl:apply-templates/></ol>
    </xsl:when>
    <xsl:otherwise>
      <ul><xsl:apply-templates/></ul>
    </xsl:otherwise>
  </xsl:choose>    
</xsl:template>

<xsl:template match="item">
  <li><xsl:apply-templates/></li>
</xsl:template>


Ce qui m'emb�te un peu est de pas pouvoir mettre en facteur le
<xsl:apply-templates/> de liste, mais bon...

Manque plus que la g�n�ration de la toc et ce sera fini pour HTML.
-- 
---------------------------------------------------------
�ric Jacoboni       � No sport, cigars! �  (W. Churchill)
---------------------------------------------------------

>>>>> "Thierry" == Thierry Bezecourt <thbz@thbz.cx> writes:

Thierry> G�n�rer une table des mati�res ne me para�t pas si facile que cela
Thierry> avec expat. 

Je voulais dire avec XML::Parser... En fait, l'avantage que j'y vois
est que je peux concilier le traitement de XML par XML::Parser et le
traitement du fichier brut par Perl (deux choses que je ma�trise bien
maintenant). Je ne dis pas que c'est plus lisible, encore que :

sub section { 
  $section +=1;
   print "<a name = \"sect_$section\"><h2>$section. ". $_[3]."</h2></a>"; 
}

sub toc {
    my $sect = 1;
    print "<hr>\n";
    print "<center><h2><em>Table des mati&egrave;res</em></h2></center><p>\n";
    print "<ul>";
    open (FIC, $fichier) or die "$!\n";
    while (<FIC>) {
       print "<li><a href=\"\#sect_".$sect++."\">$1</a></li>\n" 
              if (/<section titre.*=.*\"(.*?)\"/);
    }
    print "</ul>";
    close FIC;
}

ne soit pas le bout du monde...


Thierry> Avec XSLT, c'est beaucoup plus propre

Je ne le nie pas. Mais j'ai l'impression que cette propret� � un prix...

Thierry> <xsl:template name="toc">
Thierry>   <!-- s�lectionner chaque chapitre et afficher son titre -->
Thierry> </xsl:template>  

Elle est bien bonne ;-)

Pour qu'une toc HTML soit efficace � mon sens, elle doit ressembler de
pr�s ou de loin � une liste contenant des liens <a href=...> vers
chaque t�te de section (je passe sur les d�coupages inf�rieurs). Or
pour que ces liens soient faits il faut que les t�tes de section
placent une r�f�rence <a name=...> (voir le code Perl ci-dessus). Vu
que la toc appara�t _avant_ la premi�re section, j'ai du mal �
imaginer comment g�rer ce truc en XSLT (c'est s�rement possible, mais
bon...).

C'est s�r qu'en utilisant un .xls d�j� �crit par un organisme
comp�tent, j'y arriverais... Toutes proportions gard�es, c'est ce que
je fais avec Docbook en utilisant un html.dsl perso qui se borne �
dire (define %generate-article-toc% #t) et, c'est le cas de le dire :
toc ! Mais cela va � l'encontre de mon principe directeur consistant �
utiliser le moins possible d'outils.

Cela dit, le probl�me ne se pose qu'avec HTML qui ne dispose pas de
m�canisme int�gr� pour les toc. En LaTeX (pardon pour cette
comparaison audacieuse), 


sub toc {
    print "\\tableofcontents";

}

et roulez jeunesse...

Il en irait de m�me pour toute transformation vers une DTD d�finissant le
m�me m�canisme...

Thierry>Je n'aime pas la syntaxe de XSLT (<xsl:value-of select="@title" />,
Thierry> c'est lourd...), mais la logique qui est derri�re (templates + XPath)
Thierry> est vraiment s�duisante.

Ce n'est pas tant la syntaxe qui me g�ne que la volont� d�lib�r�e (et
s�rement louable pour ceux � qui c'est destin�) de cacher toute la
logique de traitement et, quand on a l'habitude de programmer � � sec �,
c'est pour le moins d�concertant...
-- 
---------------------------------------------------------
�ric Jacoboni       � No sport, cigars! �  (W. Churchill)
---------------------------------------------------------

Eric Jacoboni <jaco@titine.fr.eu.org> writes:

> Thierry> <xsl:template name="toc">
> Thierry>   <!-- s�lectionner chaque chapitre et afficher son titre -->
> Thierry> </xsl:template>  
> 
> Elle est bien bonne ;-)
> 
> Pour qu'une toc HTML soit efficace � mon sens, elle doit ressembler de
> pr�s ou de loin � une liste contenant des liens <a href=...> vers
> chaque t�te de section (je passe sur les d�coupages inf�rieurs). Or
> pour que ces liens soient faits il faut que les t�tes de section
> placent une r�f�rence <a name=...> (voir le code Perl ci-dessus). Vu
> que la toc appara�t _avant_ la premi�re section, j'ai du mal �
> imaginer comment g�rer ce truc en XSLT (c'est s�rement possible, mais
> bon...).

Ok, je n'avais pas pens� que c'�tait � ce point-l� que tu
pensais. Mais, l� encore, XSLT a tout pr�vu... La fonction
generate-id() fait la magie n�cessaire, c'est-�-dire g�n�rer un
identifiant pour le noeud courant :

  <xsl:template match="book">
   <xsl:apply-templates select="chapter" mode="toc" />
   <xsl:apply-templates select="chapter" mode="contenu" />
  </xsl:template>
  
  <xsl:template match="chapter" mode="toc">
   <a href="#{generate-id()}"><xsl:value-of select="@title" /></a>
  </xsl:template>
  
  <xsl:template match="chapter" mode="contenu">
   <a name="{generate-id()}"><xsl:apply-templates /></a>
  </xsl:template>

Oui, bien s�r, si tu continues � chercher, tu vas finir par vraiment
tomber sur des limitations de XSLT. Mais je trouve que �a le vaut le
coup d'essayer un peu XSLT, ne serait-ce que pour changer des langages
de programmation et voir qu'un autre mod�le peut �tre remarquablement
puissant.


-- 
Thierry B�zecourt

Eric Jacoboni a �crit dans <87n1i1eygo.fsf@titine.fr.eu.org>
> >>>>> "(TOM)" == (TOM)  writes:
> (TOM)> Tu n'as pas � t'occuper du processeur XSLT qu'auront les "lecteurs"
> (TOM)> eventuels de tes documents (si tu les distribuent ensemble).
>
> Oui, vu sous cet angle... Moi je partais du principe que :
>
> 1) tout syst�me s�rieux � Perl
> 2) j'envoyais le doc XML + la DTD + les scripts de transformation
> 3) il suffit au lecteur d'installer XML::Parser en trois coups de
>    cuill�re a pot (un appel � make), il a le html, le tex, le docbook.

Ah, tout syst�me s�rieux doit donc aussi avoir make ;o) (enfin en g�n�ral
les modules Perl ils s'installent avec un 'perl Makefile' ou quelque chose
du style non ?)

Bon, pour trancher, on va dire (encore une fois) qu'il bien entendu voir au
cas par cas (tu sais que les destinataires ont Perl donc...)

> (TOM)> XSLT est plus puissant qu'un processeur SAX comme Expat
>
> Peut-�tre, je ne connais pas suffisamment pour juger, je parlais du
> point de vue qui est le mien : je ma�trise suffisamment bien la
> programmation pour que la confection de scripts ne me pose pas de
> probl�me. D'o� la question sur l'int�r�t d'apprendre un autre
> langage. Je pense que le r�el atout de xls est, comme le dit Doeni,
> est sa facult� de g�n�ration � � la vol�e �.

Bah en Perl (ou autre) aussi, c�t� serveur (tu parles de g�n�ration), avec
un b�te script/programme appel� via CGI. C�t� client, on en revient � ma
premi�re remarque : tu en es ind�pendant.

> (TOM)> Avec expat (utilis� avec PHP pour ma part ;o) , pas facile et
> (TOM)> surtout peu lisible, avec XSLT c'est un jeu d'enfant.
>
> Mouais, il suffisait de d�clarer une variable pour m�moriser le titre
> de la section en cours, non ?

Oui bien s�r (en plus, et surtout, de compter pour le "une fois sur 2" et
2-3 autres bricoles), vraiment rien de compliqu�, mais bien moins trivial
qu'avec XSLT (j'ai m�me fait pire : comme j'avais que 5 docs minuscules,
j'ai pris mes mimines, mon copier/coller et mes search/replace). Pour info,
la feuille XSLT ressemblerait (en tr�s et en coupant le "non-d�terminant") �
:
<!--
  pour ceux qui maitrisent XSLT, notez que ce sont quasiment mes premi�res
  feuilles XSLT (j'en suis m�me niveau de test que toi Eric ;o) , alors un
  peu d'indulgence et surtout corrections et am�liorations sont les bien
  venues !
-->
<xsl:template match="section">
  <xsl:variable name="impair" select="boolean(position() % 2)"/>
  <table summary="{titre}"><tr>
  <xsl:choose>
    <xsl:when test="$impair">
      <th><xsl:value-of select="titre"/></th>
      <td><xsl:value-of select="texte"/></td>
    </xsl:when>
    <xsl:otherwise>
      <td><xsl:value-of select="texte"/></td>
      <th><xsl:value-of select="titre"/></th>
    </xsl:otherwise>
  </xsl:choose>
</tr></table>
</xsl:template>

De mon point de vue (et j'insiste l� dessus), c'est plus
lisible/compr�hensible.

> Dans le m�me ordre d'id�e, g�n�rer une
> table des mati�res dans la transformation HTML est facile avec Expat,
> je tremble � l'id�e de le faire avec XSLT...

Tu ne "match" que les �l�ments que tu veux :
<xsl:template match="/">
  ...
  <ol>
    <xsl:apply-templates select="chapitre"/>
  </ol>
  ...
</xsl:template>

<xsl:template match="chapitre|section|paragraphe">
  <li>
    <xsl:value-of select="@titre"/>
    <xsl:choose>
      <xsl:when test="descendant::section">
        <ol>
          <xsl:apply-templates select="section"/>
        </ol>
      </xsl:when>
      <xsl:when test="descendant::paragraphe">
        <ol>
          <xsl:apply-templates select="paragraphe"/>
        </ol>
      </xsl:when>
    </xsl:choose>
  </li>
</xsl:template>

Et encore, c'est pas franchement lisible parce que j'ai condens� (un
template au lieu de 3) , j'aurai pu aussi rajouter tr�s facilement des
liens, une num�rotation g�r�e par XSLT (pour par exemple avoir une
num�rotation � plusieurs niveaux : 1 (1.1, 1.2, 1.3), 2 (2.1, 2.2, 2.3) par
exemple) plutot que par HTML (ce qui permet de num�roter aussi avec d'autres
formats de sortie), etc.

Bien s�r, ca ne demande pas la m�me tournure d'esprit, et dans le cas d'une
table des mati�res, o� on respecte l'ordre des �l�ments, etc. on n'a pas
besoin d'avoir l'arbre complet en m�moire, une programmation �v�nementielle
(donc avec quelque chose comme expat) est je pense plus adapt�.

Encore une fois, il n'y a pas moyen de trancher et SURTOUT, il n'y a pas de
raison de trancher ! S'il existe les 2 approches (SAX et DOM), c'est
qu'elles sont compl�mentaires.
--
Voili voilou

(TOM)

Eric Jacoboni <jaco@titine.fr.eu.org> writes:

> (TOM)> Avec expat (utilis� avec PHP pour ma part ;o) , pas facile et
> (TOM)> surtout peu lisible, avec XSLT c'est un jeu d'enfant.
> 
> Mouais, il suffisait de d�clarer une variable pour m�moriser le titre
> de la section en cours, non ? Dans le m�me ordre d'id�e, g�n�rer une
> table des mati�res dans la transformation HTML est facile avec Expat,
> je tremble � l'id�e de le faire avec XSLT...

G�n�rer une table des mati�res ne me para�t pas si facile que cela
avec expat. Soit tu parses deux fois le document avec des handlers
diff�rents, une fois pour la table des mati�res, une autre fois pour
le corps du document. Soit tu parses une seule fois, et il faut que tu
te fasses ta structure de donn�es � toi pour stocker tout ce qu'il te
faut, avant de g�n�rer l'ensemble du HTML � la fin. Bref, avec expat
on finit souvent par se faire son propre mini-DOM, et il faut le
maintenir quand on fait �voluer le type du document.

Avec XSLT, c'est beaucoup plus propre, parce que le code qui g�n�re le
HTML reste au plus pr�s de celui-ci qui parcourt le document XML :

<!-- Docbook -->
<xsl:template match="book">
  <!-- TOC     -->  <xsl:call-template name="toc" />
  <!-- contenu -->  <xsl:call-template name="contenu" />
</xsl:template>

<xsl:template name="toc">
  <!-- s�lectionner chaque chapitre et afficher son titre -->
</xsl:template>  

<xsl:template name="contenu">
  <!-- appliquer un template "chapter" qui affiche le contenu de
  chaque chapitre en appelant les templates "section", etc... -->
</xsl:template>

Je n'aime pas la syntaxe de XSLT (<xsl:value-of select="@title" />,
c'est lourd...), mais la logique qui est derri�re (templates + XPath)
est vraiment s�duisante.


-- 
Thierry B�zecourt