Choix outils de transformation

Bonjour,

Je suis toujours sur mes tests et mes choix pour la manipulation de "gros" documents.

Une de mes idées :

Code:

---

1 2 3 4 5 6 7 8

<Root> <A>...</A> <A>...</A> <A>...</A> <A>...</A> ... </Root>

---

Dans ce document ca serait de monter en mémoire chaque élément A (type complexe) de le traiter puis de passer au suivant sans avoir à monter tout le document... Donc exit XSL qui monte l'arbre en entier... JDOM pareil... SAX je suis pas fan...

Je me suis tourné vers Castor et le mashalling... mais je débute et je ne sais pas si ce que je souhaite faire est possible avec Castor ? Apparemment il monte le document en entier en mémoire non ?

Avez-vous d'autres pistes pour ce genre de problématique ?

Merci d'avance ;)

Haaz

PS : je bosse en java

Bonjour,

juste une petite intervention pour dire que je serais moi même preneur d'un parseur que serait capable de monter en mémoire une partie seulement d'un fichier xml de très grosse taille.

je pensais jusqu'à présent qu'il n'y avait pas d'autre choix dans les parser que DOM ou SAX (quelques soit le language ). donc pas d'autre choix que "tout en mémoire" ou "evènementiel". ;)

concernant castor, voilà ce que j'ai trouvé :

Citation:

---

Castor XML is dependent on the latest release of Xerces available from the library directory and XML Apache. Other XML parser may be used instead of Xerces, however, Xerces is required to provide the XML serializer package for XML document production.

---

ce qui donne à penser qu'il doit effectivement passer tout en mémoire.

pas d'idée sur d'autre parser, désolé :oops:

mais si je trouve, je te tiens au courant :)

:D

Tu as précisé que tu travaillais sur Java.
Je veux juste te dire comment Microsoft s'y est pris pour traiter les gros documents Xml dans sa nouvelle plateforme .NET.

L'espace de nom "System.Xml" (équivalent de package Java) comprend une classe abstraite XmlReader dont est dérivé la classe XmlTextReader.

XmlTextReader permet de lire une version sérialisée du document Xml avec un curseur vers l'avant sans mise en cache (ou si peu). Tu lis le document noeud par noeud en testant à chaque fois le type mais sans que le processeur ne charge le document.

L'autre classe principale XmlValidatingReader permet de lire en validant le document à la volée.

Zoltar.

Bonjour,

Mm je ne sais pas trop comment ca fontionne... tu peux donc choisir un noeud et le monter en entier en mémoire avec cette méthode ?
Par curiosité la question parce qu'on bossera pas avec .NET mais c'est toujours bon de savoir

Bon Castor m'a l'air très très utile ! seul bémol... au lieu de monter un arbre DOM en mémoire je monte des collections JAVA... moins gourmand je suppose mais toujours pas ce que je veux...

Du coup je vai svoir du coté d'Oracle et de leur XDK... peut etre que je vias trouver mon bonheur vu que une BD contient beaucoup de donnés (sisi) ils ont du avoir le problème...

HELP ! ... j'aurias testé toutes les méthodes de parsing possible à force...

Haaz

Salut

Moi par contre je suis curieux de savoir comment tu récupères l'arborescence d'un document Xml pour le traiter avec le Dom en Java.
J ai le bouquin "Xml avec java 2" (pas le temps de le lire) mais je sais pas si les classes installées sur ma bécane comprennent les classes du Xml ?
C'est Jaxp ? C'est ça ? Y a d'autres processeurs Java "non Sun" ?
Est ce que tu connais un site ou il ya de la doc abordable pour Xml avec Java 2 ?
Si tu veux un site de xml pour .NET, essaye www.xmlforasp.net

Zoltar.

Salut,

Pour les traitements en java j'utilise JDOM ce qui pour charher un doc en mémoire ressemble à ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

SAXBuilder builder = new SAXBuilder("org.apache.xerces.parsers.SAXParser"); builder.setValidation(true); builder.setFeature( "http://apache.org/xml/features/validation/schema", true); builder.setProperty( "http://apache.org/xml/properties/schema/external-noNamespaceSchemaLocation", schema); builder.setErrorHandler(adlErrorHandler);   try { this.document = builder.build(is); } catch (JDOMException e1) { throw new AdlParserException( "JDOM Exception : Erreur de parsing du fichier XML", adlErrorHandler.getErrInfo()); } catch (IOException e2) { throw new AdlParserException( "IOException : Erreur de parsing du fichier XML", adlErrorHandler.getErrInfo()); }

---

Bon de mon coté vouloir tester les outisl oracle/XML c'est bien mais faut passer du temps à configurer les tables et le reste... (SQL pour les nuls et hop...)

Je suis le seul à avoir la problèmatique de GROOOOS documents ???

Haaz

Citation:

---

Envoyé par Haazheel

Je suis le seul à avoir la problèmatique de GROOOOS documents ???

---

à la base, XML n'est pas fait pour traiter des gros documents !!!

Citation:

---

à la base, XML n'est pas fait pour traiter des gros documents !!!

---

Je ne suis pas tout à fait d'accord... SAX te permet de traiter les documents de la taille que tu veux non ?

Disons que ce n'est peut etre pas le mieux adapter mais cela va donner pas mal de plus à nos applis.

Je suis en train de tester StAX là et ca m'a l'air parfait... je reviens vous donner le réultat de mes tests mais c'est plus rapide que SAX et équivalent en mémoire ;) avec des fonctionnalités très intéressantes !

Haaz

Citation:

---

Envoyé par Haazheel

Citation:

---

à la base, XML n'est pas fait pour traiter des gros documents !!!

---

Je ne suis pas tout à fait d'accord... SAX te permet de traiter les documents de la taille que tu veux non ?

---

je ne parlais pas du point de vue logiciel mais du point de vue théorique
à la base le XML est un "langage" de transfert et aussi un langage qui est lisible en même temps par la machine et l'homme
je trouve donc normal que les gros fichiers XML existent mais seulement pour le transfert d'un ordi à un autre par exemple. ensuite quand les données doivent être traitées ou lues régulirement il n'y a plus de problèmes de transfert et donc les données se sentiront mieux dans un SGBDD

tout ca c'est mon avis perso mais je suis toujours pret à écouter des avis différents puisque c'est comme ca qu'on évolue ;)

Citation:

---

les données se sentiront mieux dans un SGBDD

---

Tout à fait d'accord !
Maintenant si tu changes de SGBD... t'es bon pour refaire pas mal de traitement sur tes données... genre tout refaire ton php pour attaquer ta base ou tout pleisn d'autres applis...
Si tu extrait les données de ton SGBD en XML et que ensuite tu ne travaille que sur le XML... si tu changes de SGBD ben il te reste à coder l'insertion et l'extraction des données en XML et c'est tout !

BOn tu vas me répondre que si tu abandonne le XML t'a tout à refaire... oui ok mais bon XML ca s'abandonne pas ! :)

De plus si l'envie de prend de vouloir générer des PDF ben t'as deja le XML !

Ceci étant dit je suis 100% d'acocrd avec toi et j'ai bien expliqué que ca me gonflait de devoir traiter des fichiers de plus de 20Mo alors que j'avias deja tout fait avec JDOM, que je maitrisais plus ou moins les manips et que maintenant je dois "tout" refaire car c'est inadapté pour de trop gros doc...

J'espere que StAX va me sauver la vie... allez j'y retourne !

Haaz