Qu'entends-tu exactement par exhaustive, ou, plus précisément, que manque-t-il ?
Je pense notamment a une documentation d'API. Connaître toutes les directives pour chaque langage la partie xml et des documentations d'API pour leurs utilisation en C/C++ et Java.
Ah oui, la doc. sur l'API… Le problème, c'est qu'une documentation là-dessus n'aurait pas de sens sans documentation sur le framework sur lequel elle s'appuie, les deux étant imbriqués (p. ex., autant le parser XML que le préprocesseur proprement dit font partie intégrante du framework). Or, cette documentation est inexistante (même moi, utilisateur quotidien de ce framework, n'en ai pas). Et rédiger une documentation sur un framework qui existe depuis plus de dix ans, et qui n'a cessé d'évoluer depuis, représente un travail titanesque, d'autant plus que les concepts mis en œuvre sont un peu particuliers.
Je ne peux entreprendre un tel travail sans être sûr d'avoir un minimum de retour sur investissement sous une forme ou une autre. Oui, je sais, c'est le serpent qui se mord la queue ; personne ne s’intéressera au code tant qu'il n'y aura pas de doc., et je ne rédigerais pas de doc. tant que personne ne s’intéressera au code. Et, en tout honnêteté, la documentation je ne sais pas (ce qui a toujours grever mes notes de projet durant mes études d’informatique) et je n'aime pas faire (les deux étant probablement liés), ce qui n'aide pas…
Pour cet usage, pouvoir placer directement les directives de transformation dans les fichiers sources me semble plus pratique que de maintenir un fichier dédié à part, comme c'est le cas avec XSLT.
Je comprends, dans d'autres cas ça peut être considéré comme une contrainte. C'est à prendre en compte.
d'autant que je ne sois pas convaincu qu'il soit vraiment pertinent de comparer les deux
C'est pour ça que je te demandais le positionnement de l'un par rapport à l'autre. Pour quelqu'un qui découvre, quand on parle de transformation xml on a le réflexe de penser à XSL (du coup c'est peut être un point à ajouter dans ta FAQ ? :) ).
C'est l'éternel problème. A force d'utiliser cet outil quotidiennement, les différences entre les deux approches me paraissent tellement évidentes que j'ai du mal à concevoir que ce ne soit pas le cas pour tout le monde. Ceci dit, je pensais que l'exemple dans la page des directives était suffisamment explicite pour mettre en évidence ces différences.
J'en demande des trucs, hein ?
Ben si j'avais voulu qu'on ne m'en demande pas, je n'aurais pas rédigé ce journal…. :-)
En tout cas je te remercie ça m'a l'aire vraiment intéressant. Je testerais quand j'aurais l'occasion de me confronter à ce genre de choses.
Merci à toi de t'y intéresser :-) !
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: Doc
Posté par Claude SIMON (site web personnel) . En réponse au journal Nouvelle version de 'expp', le préprocesseur XML du projet Epeios.. Évalué à 1.
Ah oui, la doc. sur l'API… Le problème, c'est qu'une documentation là-dessus n'aurait pas de sens sans documentation sur le framework sur lequel elle s'appuie, les deux étant imbriqués (p. ex., autant le parser XML que le préprocesseur proprement dit font partie intégrante du framework). Or, cette documentation est inexistante (même moi, utilisateur quotidien de ce framework, n'en ai pas). Et rédiger une documentation sur un framework qui existe depuis plus de dix ans, et qui n'a cessé d'évoluer depuis, représente un travail titanesque, d'autant plus que les concepts mis en œuvre sont un peu particuliers.
Je ne peux entreprendre un tel travail sans être sûr d'avoir un minimum de retour sur investissement sous une forme ou une autre. Oui, je sais, c'est le serpent qui se mord la queue ; personne ne s’intéressera au code tant qu'il n'y aura pas de doc., et je ne rédigerais pas de doc. tant que personne ne s’intéressera au code. Et, en tout honnêteté, la documentation je ne sais pas (ce qui a toujours grever mes notes de projet durant mes études d’informatique) et je n'aime pas faire (les deux étant probablement liés), ce qui n'aide pas…
C'est l'éternel problème. A force d'utiliser cet outil quotidiennement, les différences entre les deux approches me paraissent tellement évidentes que j'ai du mal à concevoir que ce ne soit pas le cas pour tout le monde. Ceci dit, je pensais que l'exemple dans la page des directives était suffisamment explicite pour mettre en évidence ces différences.
Ben si j'avais voulu qu'on ne m'en demande pas, je n'aurais pas rédigé ce journal…. :-)
Merci à toi de t'y intéresser :-) !
Zelbinium: pour la génération qui crée, pas celle qui scrolle...