C'est sûr. Sauf que le modèle est quand même l'un des vrais points forts d'XML, donc, utiliser le fait que le parser ne soit pas trop compliqué en oblitérant une fonctionnalité phare pour dire que ce n'est pas si dur/long/whatever me paraît... douteux.
Sinon, si on parles du simple parsing ( en espérant ne pas me planter et ne pas en oublier trop ):
Il faut être capable de lier à , mais savoir que si on rencontre alors pas de balise fermante.
%XX génère un octet de valeur hexa XX.
%% génère un %.
&foobar; génère le caractère foobar.
" est un délimiteur. ' aussi. Ils peuvent être imbriqués de mémoire.
En terme de coût CPU, je trouve que c'est assez coûteux. Après, je ne nie pas que tous les langages ont des libs plus ou moins bien foutues pour le faire à notre place, mais ça ne veut pas dire que leur implémentation est triviale, surtout quand il y a un besoin de performances.
Un collègue à tenté d'utiliser je ne sais plus quel parseur php, le résultat était misérable en terme de perf, il à donc dû en implémenter un lui-même. Je gage que j'arriverais à faire bugguer le code en question sans trop de souci, en jouant sur les assertions non vérifiées.
Si cet outil php est lent, il doit bien y avoir une raison... ou juste peut-être que mon collègue s'en est mal servi, je n'en sais rien ( je n'étais pas dans la boîte à ce moment, donc je ne connaît pas tous les tenants et aboutissants ).
[^] # Re: XML
Posté par freem . En réponse au journal XML c'est de la daube!!!. Évalué à 2.
C'est sûr. Sauf que le modèle est quand même l'un des vrais points forts d'XML, donc, utiliser le fait que le parser ne soit pas trop compliqué en oblitérant une fonctionnalité phare pour dire que ce n'est pas si dur/long/whatever me paraît... douteux.
Sinon, si on parles du simple parsing ( en espérant ne pas me planter et ne pas en oublier trop ):
Il faut être capable de lier à , mais savoir que si on rencontre alors pas de balise fermante.
%XX génère un octet de valeur hexa XX.
%% génère un %.
&foobar; génère le caractère foobar.
" est un délimiteur. ' aussi. Ils peuvent être imbriqués de mémoire.
En terme de coût CPU, je trouve que c'est assez coûteux. Après, je ne nie pas que tous les langages ont des libs plus ou moins bien foutues pour le faire à notre place, mais ça ne veut pas dire que leur implémentation est triviale, surtout quand il y a un besoin de performances.
Un collègue à tenté d'utiliser je ne sais plus quel parseur php, le résultat était misérable en terme de perf, il à donc dû en implémenter un lui-même. Je gage que j'arriverais à faire bugguer le code en question sans trop de souci, en jouant sur les assertions non vérifiées.
Si cet outil php est lent, il doit bien y avoir une raison... ou juste peut-être que mon collègue s'en est mal servi, je n'en sais rien ( je n'étais pas dans la boîte à ce moment, donc je ne connaît pas tous les tenants et aboutissants ).