fais donc je t en prie
heureusement qu on est encore ouvert a l argumentation

des APIs differentes ? il doit y avoir confusion vu que je ne vois que DOM, SAX et eventuellement StAX et E4X
getAttributes, getChildNodes... normalise tout ca

probleme de librairies entre plateformes ?
c est lie avec le DOM ca... si les parsers utilises ne s y conforment pas on peut pas y faire grand chose

> ... sauf qu'un parseur XML c'est tout sauf simple (en interne) :-)
je me suis mal exprime
je voulais dire que des parseurs bien plus complexes existaient deja pour le SGML et qu ils etaient presque totalement reuitilisables pour le XML (les parseurs xml sont simples en comparaison)

> Par rapport au parsing d'un fichier tabulaire ou un simple
> fichier .ini, les parseurs XML consomment nettement plus de
> mémoire et plus de CPU... pour le même résultat.
pour le meme resultat ?
pardon mais c est exagere
cela me rappelle quelqu un qui disait qu il etait simple de creer un parseur de csv... pas si simple en prenant en compte les retours chariot et l encodage
qu ils consomment plus c est un fait mais ce n est pas a mon sens un killer argument compte tenu de la puissance apportee
pourquoi creer des parseurs differents aussi simples soient ils pour gerer fonctionnellement le meme besoin ? (et tous les besoins annexes de definition, de validation, d extensibilite)
oui on peut penser que c est utiliser un bulldozer pour ecraser une mouche... je prefere dire que c est un outil tres polyvalent et qu on aurait bien tort de s en priver (disons plutot que l analogie est mal choisie de mon point de vue)

maintenant on ne me fera jamais dire qu xml est utilisable partout
en revanche pour tout ce qui est internet il n y a pas photo, lorsqu on a un besoin de format documentaire pivot idem (et c est souvent), passer des donnees hierarchisees entre composants etc