Quelques indications pour la correction du projet : ---------------------------------------------------- Les sources : ------------- 1/ La qualité du code C Ce n'est pas le sujet. 2/ La gestion des options Ce n'est pas le sujet. Plusieurs solutions : a/ trois programmes Yacc et un script de lancement. b/ un seul programme Yacc et des "switch" dans chaque action c/ un seul programme Yacc qui fait toutes les options systématiquement grâce à une structure plus volumineuse. d/ un seul programme Yacc qui mixte b/ et c/ (c'est ma solution) Le fichier LEX : ---------------- 3/ Les balises Pas de difficulté pour la liste des "marques". Il faut faire attention aux minuscules et aux majuscules. 4/ Les commentaires C'est pas simple, car ils peuvent englobés des balises et être sur plusieurs lignes. Il y a au moins trois solutions : a/ les commentaires ne sont pas envoyés à Yacc. source "html_Va.lex" C'est la solution la plus simple, (on utilise un état dans lex), c'est celle qui est généralement utilisée pour les langages, mais on perd les commentaires dans le fichier résultat. b/ les commentaires sont envoyés à Yacc et la grammaire est changée. Cette solution est compliquée et a été déconseillée. c/ Les commentaires sont envoyés à Yacc, et ils sont "intégrés" aux autres terminaux afin de ne pas modifier la grammaire. Ils sont alors retranscrits dans le résultat. Cette solution est assez compliquée au niveau du "lex", car l'expression rationnelle des commentaires n'est pas simple. source "html.lex" COMMENT \])|[^\-])*-\> 5/ Le terminal CHAINE Cela dépend de la solution retenue pour les commentaires. a/ Pas très difficile, en utilisant les propriétés (de plus long motif). b&c/ Très difficile à écrire (il ne doit contenir aucun sous-mot qui soit une balise, car les mots peuvent être accolés aux balises). Dans ma correction, j'ai simplifié. TEXTE [^<>]* Le fichier YACC : ----------------- 6/ La hauteur de l'arbre C'est facile, il faut dans chaque règle de la grammaire écrire la bonne formule $$.hauteur = max_hauteur_non_terminaux + 1 $$.hauteur = 1 si que des terminaux $$.hauteur = 1 si "epsilon" 7/ La normalisation (fermeture des balises) C'est facile, cela concerne deux règles seulement. Il faut dans le cas ou l'option est activée, ajouter soit "" soit "

" dans la concaténation. 8/ L'extraction d'un niveau 3 points C'est plus difficile, il faut dans toutes les règles HI, ajouter un mécanisme pour déterminer le début et la fin de l'extraction. Par exemple, j'utilise "extraction == 1" pour faire l'extraction, et "optionExtraire" pour le niveau extrait. J'ai donc une ligne de ce style dans chaque règle HI. if (optionExtraire==i || (optionExtraire>i && extraction==1)) extraction++; Il faut également arreter l'extraction, si ce n'est déjà fait) lorsque le corps du document est terminé. Corps : BODY_O Liste_Sections BODY_F { if (optionExtraire>0 && extraction==1) extraction++; Le Rapport : ------------ 9/ Qualité rédactionnelle du rapport 10/ L'explication des messages générés par Yacc Normalement, la grammaire provoque les messages suivants: yacc: 44 shift/reduce conflicts yacc: 3 reduce/reduce conflicts Les shift/reduce sont tous résolus par priorité au shift. Les reduce/reduce viennent tous d'un conflit entre les règles Liste_Sections -> epsilon Texte -> epsilon Les trois conflits sont identiques, et sont tous résolus de la même façon, à savoir priorité à la règle définie le plus tôt (donc le plus petit numéro). Extrait de y.output obtenu avec l'option "-v" de Yacc : 7: reduce/reduce conflict (reduce 7, reduce 15) on BODY_F state 7 Corps : BODY_O . Liste_Sections BODY_F (4) Liste_Sections : . (7) Texte : . (15) ... BODY_F reduce 7 23: reduce/reduce conflict (reduce 7, reduce 15) on BODY_F state 23 Liste_Sections : Entete_De_Section . Liste_Sections (5) Liste_Sections : . (7) Texte : . (15) ... BODY_F reduce 7 24: reduce/reduce conflict (reduce 7, reduce 15) on BODY_F state 24 Liste_Sections : Texte . Liste_Sections (6) Liste_Sections : . (7) Texte : . (15) ... BODY_F reduce 7 Remarque : l'ordre de définition des règles est le bon !