Cliquez ici.
Accueil
 chercher             Plan du site             Info (English version) 
L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.Les listes de discussions XMLfr sont à votre disposition pour réagir sur nos articles ou simplement poser une question.Si vous ètes passionnée(e) par XML, pourquoi ne pas en faire votre métier ?XMLfr n'est heureusement pas le seul site où l'on parle de XML. Découvrez les autres grâce à XMLfr et à l'ODP.Les partenaires grâce auxquels XMLfr peut se développer.Pour tout savoir sur XMLfr.XMLfr sans fil, c'est possible !Pour ceux qui veulent vraiment en savoir plus sur XML.L'index du site.
 Commentaires et questions non techniques.Commentaires et questions techniques.

 
Cliquez ici.

xml tech : Technologies XML

[xml-tech] Re: (tres) gros fichiers XML : comment les traiter?

[xml-tech] Re: (tres) gros fichiers XML : comment les traiter?

Auteur: Robin Berjon <robin.berjon@expway.fr>
Date: 17/10/2005 - 11:10

Stephane Bortzmeyer wrote:
> Je ne pense pas que cela soit exact. Certes, les premières mises en
> oeuvre de DOM étaient avides (elles chargeaient tout le document) mais
> rien dans DOM ou dans d'autres APi non-évenementielles n'oblige à
> faire cela. Un expert DOM ici doit bien avoir un exemple d'une mise en
> oeuvre paresseuse (qui ne charge que ce qui est nécessaire, et au fur
> et à mesure) ?

En effet, rien dans la spécification ne force l'implémentation à tout
maintenir en mémoire. Ceci dit, dans la pratique, des DOMs paresseux ou
efficaces sont très rares.

Je sais qu'à Expway nous en avons en interne, et je suis sûr que
d'autres sociétés ont la même chose. Ceci dit ces représentations
paresseuses ne sont pas forcément utiles en dehors d'un produit
spécifique car elles sont très optimisées pour un usage particulier (et
pourraient donc avoir un impact catastrophique en temps de traitement
pour des usages autres). Un DOM paresseux générique demande de fournir
un bon nombre d'options permettant de le paramétrer, et on se retrouve
rapidement avec du code complexe.

Un bon exemple de représentation arborescente qui ne charge pas tout en
mémoire est XML::Twig. Ce module n'expose pas d'API DOM mais c'est un
arbre. Il est très stable et très utilisé, mais un coup d'oeil dans le
code montrera rapidement à quel point il est difficile d'être générique
dans la paresse, et probablement pourquoi peu de gens ont eu le courage
de Michel Rodriguez de prendre ce problème à bras le corps, et aussi
pourquoi après avoir eu le courage l'idée de se conformer à une API
semble superflue.

   http://search.cpan.org/~mirod/XML-Twig-3.22/Twig.pm
   http://www.xmltwig.com/xmltwig/

A noter, il devrait être possible de créer une surcouche à XML::Twig
exposant une interface DOM.

-- 
Robin Berjon
   Senior Research Scientist
   Expway, http://expway.com/
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de 
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant 
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Received on Mon Oct 17 13:10:20 2005

Archive générée par hypermail 2.1.8 le 31/10/2005 - 21:02 UTC

webmaster@xmlfr.org

 

xml tech

Discussions techniques au sujet de XML.

Cette liste est à votre disposition pour discuter en français de tout sujet technique lié à XML.



Devenez rédacteur <XML>fr et contribuez au développement du xml francophone !
Les documents publiés sur ce site le sont sous licence "Open Content"
Conception graphique
  l.henriot@online.fr  

Conception, réalisation et hébergement