Subject: Re: (tres) gros fichiers XML : comment les traiter? - msg#00040

Previous Message by Date: click to view message preview

Re: (tres) gros fichiers XML : comment les traiter?

Il faut regarder du coté des API de Pull Parsing ;) Contrairement aux API SAX, la lecture du document XML est dirigée par l'application principale . Dés détection d'une sous partie, il est possible de traiter immédiatement les données ou - mieux - constituer un sous document DOM pour traitement immédiat, avant de continuer la lecture du document source ! magicoz@xxxxxxxxxxx a écrit : >Pierre, > >Mon objectif est de parser le document XML puis de stocker les données dans >une BDD. J'ai déjà un peu regardé du coté de SAX et c'est une telle >nébuleuse que j'ai arreté d'y chercher.. de quel coté je devrais regarder >exactement pour repondre a mes besoins ? > >cdt, > >Alex / Paris > >Pierre Attar écrit: > > > >>Voir du coté de SAX et bien sur en fonction des traitements à réaliser. >>La programmation évènementielle à l'avantage de >>ne pas obliger au chargement de tout le document. >> >>Pierre >> >>At 11:39 14/10/2005, you wrote: >> >> >>>j'ai besoin de lire/parser de (tres) gros fichiers XML (350 ou 400 Mo) par >>>VBS (ou autres)...j'ai le choix entre : une méthode capable de me lire les >>>400 Mo d'un coup avant de parser OU une methode qui me découpe mon gros >>>fichier XML en plus petits fichiers. Pour le moment, je n'ai trouvé ni >>>l'une ni l'autre. Les methodes "Microsoft.XMLDOM" de MS ne me sont d'aucun >>>secours par exemple, car incapables de me charger ces 400 Mo. >>> >>> >>Pierre Attar (mailto:pat@xxxxxxxxx) >>Consultant en informatique documentaire XML >>Consultant in Structured Document engineering >>Tirème SARL (http://www.tireme.fr) >> >>Projet "Mutualiser l'effort de montée en compétences sur XML" >>http://www.mutu-xml.org/index.html >> >> >>-- >>Devenez redacteur <XML>fr et contribuez au developpement du >>xml francophone (http://xmlfr.org/infos/redacteurs/) ! >> >>Liste de diffusion "xml-tech@xxxxxxxxx" (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@xxxxxxxxx >>(mailto:xml-tech-request@xxxxxxxxx?Subject=unsubscribe) >> >> >> > >-- >Devenez redacteur <XML>fr et contribuez au developpement du >xml francophone (http://xmlfr.org/infos/redacteurs/) ! > >Liste de diffusion "xml-tech@xxxxxxxxx" (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@xxxxxxxxx >(mailto:xml-tech-request@xxxxxxxxx?Subject=unsubscribe) > > >

Next Message by Date: click to view message preview

Re: relaxNG : déterminer les souséléments possibles

Merci Eric ! Comme tu le dis c'est un sujet passionnant, mais qui se complexifie au fur et à mesure que j'avance... J'apprend bcp cependant et le challenge en vaut la peine. Au départ j'avais fait une recette maison, puis grâce à xml-fr j'ai découvert RelaxNG et il y a pas longtemps la programmation "100% déclarative" en xsl ! Ce qui est difficile c'est de lier les impératifs, les échéances du projet et la réalisation d'un code propre, ré-exploitable, prévu pour du long terme... ce qui n'est pas toujours facile à faire comprendre à la hierarchie ! Pour ce qui est de l'élément start, c'est une erreur d'interprétation un peu rapide de la doc RelaxNG de ma part. En fait dans mon schéma maison j'avais un élément <root> pour la racine et je l'ai tout simplement remplacé par start... En fait j'aurai peut être mieux fait d'utiliser <element>, à partir du moment ou je fais le choix de ne pas utiliser <grammar> ? maintenant pourquoi je me suis tant restreint, dans le choix des élément relaxNG utilisés...? Par souci de simplicité, de temps : je ne voulais pas implémenter toutes les possibilité de relaxNG et je me suis basé sur les besoins rééls des documents que j'allais devoir éditer, en me disant que je pourrais toujours implémenter le reste par la suite. Mais maintenant que j'ai tout re-codé en déclaratif, il est vrai qu'ajouter certains patern ne pose pas de grandes difficulté. Il s'agit de choisir lesquels cependant, les plus pertinents : je pense notamment au pattern <optional> (qui pourra m'être utile pour les attributs notamment) et peut être aussi les patters nommés (define/ref). petite question au passage le pattern grammar devient-il indispensable dans le cas d'utilisation de pattern nommés et/ou de l'élément start ? Il ne m'arrive jammais dans mes documents xml d'avoir des modèles de contenus récursifs comme les div, sans ça je n'aurait pas pu exclure les patterns nommés, en revanche ils pourront être utiles pour éviter de redéfinir plusieurs fois des patterns identiques. Je pense aussi peut être utilisé le pattern <externalRef>, pour avoir la possibilité d'éditer un document externe (mes doc xml font références les uns aux autres avec des liens par id). Mais avant d'implémenter tout cela je voulais vérifier la faisabilité du projet sur un schéma très simple n'utilisant que les quelques patterns cités. Pour ce qui est des contenus du type (B1, C1) & (B2, C2) comme j'avais mis dans mon exemple... disons que ce n'est pas un cas réél, mais m'étant limité aux éléments cités, je me suis dit qu'il fallait prévoir toutes les combinaisons de ces éléments donc j'ai fait un exemple un peu tordu exprès. La solution n'est peut être pas de limité uniquement les types d'éléments mais surtout la manière de les imbriquer alors... ? Après tout, il m'est tout à fait possible de mettre des consignes à l'écriture du schéma : "n'utilisez que tels éléments et ne les imbriquez que de cette manière ou de cette autre mais pas comme ceci ou comme cela"... c'est peut être vers ça que je devrais me pencher... compte tenu des impératifs de temps et des autres développements qui m'attendent... Car mes document xml sont en fait très simples en réalité, je les ai écrit en restant très déterministe, les seuls cas rencontrés sont : * une suite d'éléments différents apparaissant une seule fois chacun et dans un ordre prédéfinis : <element name="A"> <element name="B"/> <element name="C"/> <element name="D"/> </element> * ou un élément qui peut contenir une liste de X et/ou Y (zeroOrMore, chacun) dans n'importe quel ordre <element name="conteneur"> <interleave> <zeroOreMore> <element name="X"/> </zeroOreMore> <zeroOreMore> <element name="Y"/> </zeroOreMore> <interleave> </element> J'utilise l'élément group dans le seul but de définir un ensemble d'éléments "adjacents" à éditer en une seule fois : dans le menu arborescent (cf. 1er message) représentant le document xml (qui permet de choisir quelle noeud on veut éditer) les group apparaisent également et permette d'éditer non pas un seul noeud mais plusieurs (on envois plusieurs paramètres XpathNode à la feuille de style qui applique chacun des template) Je vais essayer la méthode que tu me conseilles (exécuter en chaîne une série de templates dans des modes différents)... je n'ai pas regardé dans le détail encore. Je suis trop avancé dans le projet pour changer XSLT par un langage de programmation, mais xslt n'est-il pas le mieux adapter pour ce type de traitement réccursif sur une syntaxe xml ? Pour info tu penses à quel(s) langage(s) par exemple ? il y a une partie asp/vb dans mon projet qui me permet de manipuler le dom des documents xml : le formulaire html envois les valeurs des "champs" (attribut ou text) à modifier et ils sont modifiés par script asp. De même pour l'ajout des noeuds, même si les boutons sont affichés par xsl, au final j'envois les paramètres (quel noeud à ajouter, sous quel noeud etc) à une page asp qui se charge d'effectuer le travail (sans contre validation) >Personnellement, je pense que, quelque soit le langage de programmation, >je travaillerais sur un schéma RELAX NG simplifié et chercherais à >m'inspirer de la méthode déclarative décrite par James Clark : >http://www.thaiopensource.com/relaxng/derivative.html. Qu'entend tu par simplifié ? restreind à qq élément et/ou imbriqué de manière déterminée (cf plus haut)? J'ai jeté un coup d'oeil à la methode de James Clark et ... humm faudra que je plonge plus dedans parce que survolé comme ça, j'avoue que je ne comprend rien... il n'y aurait pas un petit exemple de "dérivée du schéma par le document" quelque part ? >Pour faire cela en XSLT, vous pourriez vous appuyer sur la bibiothèque >FXSL (http://fxsl.sourceforge.net/) ou, si cela vous fait peut (il y a >de quoi) faire une série de passes successives en utilisant une fonction >node-set (personnellement je préfère cela à dyn:evaluate(). J'avais déjà entendu parler de cette bibliothèque FXSL, mais ça fait beaucoup de choses à découvrir, je vais butiner un peu sur le site histoire d'avoir quelques idées de ce qu'elle permet. Merci en tout cas pour toutes ces pistes, j'étais bloqué et démotivé, là ça permet de rebondir ! Matthieu.

Previous Message by Thread: click to view message preview

Re: (tres) gros fichiers XML : comment les traiter?

Il faut regarder du coté des API de Pull Parsing ;) Contrairement aux API SAX, la lecture du document XML est dirigée par l'application principale . Dés détection d'une sous partie, il est possible de traiter immédiatement les données ou - mieux - constituer un sous document DOM pour traitement immédiat, avant de continuer la lecture du document source ! magicoz@xxxxxxxxxxx a écrit : >Pierre, > >Mon objectif est de parser le document XML puis de stocker les données dans >une BDD. J'ai déjà un peu regardé du coté de SAX et c'est une telle >nébuleuse que j'ai arreté d'y chercher.. de quel coté je devrais regarder >exactement pour repondre a mes besoins ? > >cdt, > >Alex / Paris > >Pierre Attar écrit: > > > >>Voir du coté de SAX et bien sur en fonction des traitements à réaliser. >>La programmation évènementielle à l'avantage de >>ne pas obliger au chargement de tout le document. >> >>Pierre >> >>At 11:39 14/10/2005, you wrote: >> >> >>>j'ai besoin de lire/parser de (tres) gros fichiers XML (350 ou 400 Mo) par >>>VBS (ou autres)...j'ai le choix entre : une méthode capable de me lire les >>>400 Mo d'un coup avant de parser OU une methode qui me découpe mon gros >>>fichier XML en plus petits fichiers. Pour le moment, je n'ai trouvé ni >>>l'une ni l'autre. Les methodes "Microsoft.XMLDOM" de MS ne me sont d'aucun >>>secours par exemple, car incapables de me charger ces 400 Mo. >>> >>> >>Pierre Attar (mailto:pat@xxxxxxxxx) >>Consultant en informatique documentaire XML >>Consultant in Structured Document engineering >>Tirème SARL (http://www.tireme.fr) >> >>Projet "Mutualiser l'effort de montée en compétences sur XML" >>http://www.mutu-xml.org/index.html >> >> >>-- >>Devenez redacteur <XML>fr et contribuez au developpement du >>xml francophone (http://xmlfr.org/infos/redacteurs/) ! >> >>Liste de diffusion "xml-tech@xxxxxxxxx" (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@xxxxxxxxx >>(mailto:xml-tech-request@xxxxxxxxx?Subject=unsubscribe) >> >> >> > >-- >Devenez redacteur <XML>fr et contribuez au developpement du >xml francophone (http://xmlfr.org/infos/redacteurs/) ! > >Liste de diffusion "xml-tech@xxxxxxxxx" (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@xxxxxxxxx >(mailto:xml-tech-request@xxxxxxxxx?Subject=unsubscribe) > > >

Next Message by Thread: click to view message preview

Re: (tres) gros fichiers XML : comment les traiter?

On Fri, Oct 14, 2005 at 11:46:55AM +0200, Pierre Attar <pat@xxxxxxxxx> wrote a message of 36 lines which said: > Voir du coté de SAX et bien sur en fonction des traitements à > réaliser. La programmation évènementielle à l'avantage de ne pas > obliger au chargement de tout le document. 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) ?