Choix d'un schema XML
Fabrice
Dans le cadre de la définition d'un format d'entrées/sortie d'un outils
de calcul scientifique, je m'intéresse de très près au format XML.
Cependant je ne maîtrise pas vraiment ce format, j'en connais juste les
principes (fichier avec balises accompagné d'une grammaire permettant la
compréhension du fichier si je ne m'abuse ?).
Pourriez-vous m'éclairer sur les choix que je serai amené à effectuer et
sur les options qui s'offrent à moi ?
Mes contraintes sont les suivantes : ce format doit pouvoir gérer des
vecteurs à n dimensions (vecteur colonne, matrice, cube...) ainsi que
l'évolution au cours du temps de ces vecteurs.
Par exemple soit une matrice :
a b
c d
que l'on range par ligne : a b c d
Une manière de stocker les données au cours du temps aurait pu être
la suivante (fichier texte en clair) :
1 a1 b1 c1 d1
2 a2 b2 c2 d2
3 a3 b3 c3 d3
...
n an bn cn dn
D'autres contraintes sont que ce fichier devra être lu rapidement (ce
qui peut sembler difficile si trop de balises sont présentes ?), qu'il
pourra contenir des entiers, réels, booléens, chaînes de caractères et
enfin qu'il existe outils libres ou propriétaires permettant d'exploiter
ce fichier (pour tracer des courbes par exemple).
Voilà, j'aimerais surtout savoir s'il existe des standards déjà existant
pour ce type de données (j'ai cru entendre parler de SVG...).
J'ai sans doute fait pleins de fautes grossières concernant le XML mais
je ne le connais que superficiellement... veuillez donc me pardonner !
Si ce format se révèle utilisable, nul doute que je prendrai le temps de
l'étudier correctement.
D'avance merci,
Philippe Poulard
voir MathML :
http://www.w3.org/TR/2003/REC-MathML2-20031021/
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
Fabrice
<Philippe....@SPAMsophia.inria.fr> wrote :
> bonjour,
>
> voir MathML :
> http://www.w3.org/TR/2003/REC-MathML2-20031021/
>
Bonjour,
Je suis allé voir ce format MathML mais il me semble à priori lourd pour
mon utilisation. Par exemple pour représenter une matrice, chaque
cellule doit être entouré d'une balise, j'imagine la perte de
performance pour parser une grosse matrice ! mais peut-être est-ce une
limitation de XML ?
Est-ce qu'on ne peut pas imaginer quelque chose comme :
<ligne> a1 b1 c1 d1 <\ligne>
<ligne> a2 b2 c2 d2 <\ligne>
...
<ligne> an bn cn dn <\ligne>
Je précise de nouveau que je suis novice en XML, désolé si je profère
des énormités...
Merci pour votre avis néanmoins....
Vincent Lefevre
Fabrice <non_v...@yahoo.fr> écrit:
> Je suis allé voir ce format MathML mais il me semble à priori lourd
> pour mon utilisation. Par exemple pour représenter une matrice,
> chaque cellule doit être entouré d'une balise,
C'est pourtant la seule solution, sinon tu perds tout l'intérêt du XML.
> j'imagine la perte de performance pour parser une grosse matrice !
Tout dépend de ton application. Bien souvent, parser prend peu de temps
car il y a tout un traitement derrière. À toi de voir...
> mais peut-être est-ce une limitation de XML ?
Ce n'est pas une limitation. C'est XML qui est fait comme ça. Cela a
des avantages.
> Est-ce qu'on ne peut pas imaginer quelque chose comme :
> <ligne> a1 b1 c1 d1 <\ligne>
> <ligne> a2 b2 c2 d2 <\ligne>
> ...
> <ligne> an bn cn dn <\ligne>
Dans ce cas autant oublier XML.
Au fait, pourquoi veux-tu utiliser XML?
--
Vincent Lefèvre <vin...@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Philippe Poulard
> On Wed, 07 Apr 2004 09:49:59 +0200, Philippe Poulard
> <Philippe....@SPAMsophia.inria.fr> wrote :
>
>
>>bonjour,
>>
>>voir MathML :
>>http://www.w3.org/TR/2003/REC-MathML2-20031021/
>>
>
>
> Bonjour,
>
> Je suis allé voir ce format MathML mais il me semble à priori lourd pour
> mon utilisation. Par exemple pour représenter une matrice, chaque
> cellule doit être entouré d'une balise, j'imagine la perte de
> performance pour parser une grosse matrice !
peut-être que MathML est trop général pour ton problème très spécifique,
et en effet, une structure sur mesure est plus adaptée; on peut tout
avec xml.
mais peut-être est-ce une
> limitation de XML ?
il faut savoir ce qu'on veut : faire du xml et dans ce cas utiliser un
analyseur xml et bénéficier de tout l'apport de ce type d'outil :
support de l'unicode, obtention d'un modèle de données, faible
sensibilité à l'évolution, découplage des données/applis, etc...
ou alors on utilise un super programme qu'on fait soit-même, et on
réinvente la roue, et elle ne sera pas aussi ronde que ça mais tournera
peut-être un peu plus vite; peut-être que perl est un candidat potentiel
pour ton problème ?
>
> Est-ce qu'on ne peut pas imaginer quelque chose comme :
> <ligne> a1 b1 c1 d1 <\ligne>
> <ligne> a2 b2 c2 d2 <\ligne>
> ...
> <ligne> an bn cn dn <\ligne>
avec ce type de structures, on est obligé :
-d'utiliser un parseur xml
-d'écrire un parseur non xml qui parse les données de chaque ligne
foutu pour foutu, autant laisser tomber xml
...ou adopter complètement xml, et pour moi ça signifie coder des
données atomiques, donc :
<ligne><c>a2</c><c>b2</c><c>c2</c><c>d2</c><\ligne>
ou alors
<ligne><c v="a2"/><c v="b2"/><c v="c2"/><c v="d2"/><\ligne>
c'est verbeux mais ça n'a jamais vraiment dérangé, si tu utilises une
structure "à moitié xml", tu te pénalise en utilisant xml sans en
retirer tous les bénéfices de structuration : super mauvais choix
pour ce qui est des volumes, les parseurs peuvent traiter des flux de
plusieurs dizaines de Mo, ou davantage en utilisant un parseur SAX;
d'après ce que j'ai compris, tu aurais d'avantage d'intérêt d'utiliser
un parseur SAX que DOM
quant aux performances, la verbosité et la structure intrinsèque de xml
font que tu auras sûrement des résultats moins probants qu'avec des
données à plat; il faudrait faire un benchmark pour s'en rendre compte;
mais si tu as 10% de gain sans xml, est-ce que cela vaut le coup ?
à toi de voir en fonction de tes contraintes : si la portabilité des
données est moins importante que des supers performances de la mort,
quitte à gagner 1%, alors laisse xml de côté
>
> Je précise de nouveau que je suis novice en XML, désolé si je profère
> des énormités...
du tout, il faut bien commencer un jour
bon, j'ai essayé d'être neutre dans ma réponse : le choix t'appartient,
mais choisi full xml ou pas du tout xml, mais pas de compromis !
>
> Merci pour votre avis néanmoins....
Franck Guillaud
> Fabrice wrote:
>>
>> Est-ce qu'on ne peut pas imaginer quelque chose comme :
>> <ligne> a1 b1 c1 d1 <\ligne>
>> <ligne> a2 b2 c2 d2 <\ligne>
>> ...
>> <ligne> an bn cn dn <\ligne>
>
>
> avec ce type de structures, on est obligé :
> -d'utiliser un parseur xml
> -d'écrire un parseur non xml qui parse les données de chaque ligne
>
> foutu pour foutu, autant laisser tomber xml
> ...ou adopter complètement xml, et pour moi ça signifie coder des
> données atomiques, donc :
>
> <ligne><c>a2</c><c>b2</c><c>c2</c><c>d2</c><\ligne>
> ou alors
> <ligne><c v="a2"/><c v="b2"/><c v="c2"/><c v="d2"/><\ligne>
>
> c'est verbeux mais ça n'a jamais vraiment dérangé, si tu utilises une
> structure "à moitié xml", tu te pénalise en utilisant xml sans en
> retirer tous les bénéfices de structuration : super mauvais choix
Je suis d'accord avec toi, mais c'est pourtant le choix qui a été fait
pour SVG. En effet les polylignes ne sont pas codées de manières "atomique".
Juste une remarque en passant.
Franck,e-
Xavier Cazin
Ç'est possible, mais dans ce cas, le XML est inutile. Un fichier texte
formaté de type csv sera beaucoup plus simple à gérer. Si vous voulez
passer dans une chaîne XML (parce que des programmes en amont écrivent du
XML, et des programmes en aval lisent du XML), alors il faudra passer par
quelque chose du genre
<matrice>
<ligne>
<composante>a1<\composante>
<composante>b1<\composante>
<composante>c1<\composante>
<composante>d1<\composante>
<ligne>
<ligne>
<composante>a2<\composante>
<composante>b2<\composante>
<composante>c2<\composante>
<composante>d2<\composante>
<ligne>
...
</matrice>
C'est effectivement très lourd, mais ça permet de convertir facilement
depuis et vers une DTD standard de type MathML si votre outil de
publication en a besoin. Plus intéressant : ça permet aussi d'inclure des
matrices dans d'autres types de document XML. Si vous n'avez pas à faire ce
type d'échange, et si vous cherchez simplement à définir un format de
données, optez pour quelque chose de moins lourd et de plus naturel.
X.
On 8 Apr 2004, non_v...@yahoo.fr wrote:
> Je suis allé voir ce format MathML mais il me semble à priori lourd pour
> mon utilisation. Par exemple pour représenter une matrice, chaque
> cellule doit être entouré d'une balise, j'imagine la perte de
> performance pour parser une grosse matrice ! mais peut-être est-ce une
> limitation de XML ?
>
> Est-ce qu'on ne peut pas imaginer quelque chose comme :
> <ligne> a1 b1 c1 d1 <\ligne>
> <ligne> a2 b2 c2 d2 <\ligne>
> ...
> <ligne> an bn cn dn <\ligne>
>
> Je précise de nouveau que je suis novice en XML, désolé si je profère
> des énormités...
>
> Merci pour votre avis néanmoins....
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Éditions O'Reilly <URL:http://www.oreilly.fr/>
18 rue Séguier
75006 PARIS Fax : +33 1 40 51 52 31
Philippe Poulard
bien vu ! on appelle ça des propriétés composées (/shorthand properties/)
je pense que c'est un mauvais choix pour svg : il a été dit qu'on se
moquait qu'xml soit verbeux, et là on fait n'importe quoi; faut savoir à
la fin ! le w3c se contredit aussi :)
pour ma part, je maintiens qu'un parseur dans un parseur n'est pas une
bonne idée
Vincent Lefevre
Philippe Poulard <Philippe....@spamsophia.inria.fr> écrit:
> pour ma part, je maintiens qu'un parseur dans un parseur n'est pas une
> bonne idée
Tout à fait. Mais XML a aussi des défauts, je pense. Par exemple,
les IDREFS. À moins que l'on considère que des noms séparés par
des espaces forment en quelque sorte une liste. Mais ça ne se gère
pas très bien par XSLT. C'est dommage. Idem pour les PI, dont la
forme est assez libre, mais qui peuvent être construites comme des
éléments, auquel cas il faut un parseur particulier pour parser
les pseudo-attributs (ou j'ai manqué quelque chose?).
--
Vincent Lefèvre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Philippe Poulard
> Dans l'article <c535pq$3i3$1...@news-sop.inria.fr>,
> Philippe Poulard <Philippe....@spamsophia.inria.fr> écrit:
>
>
>>pour ma part, je maintiens qu'un parseur dans un parseur n'est pas une
>>bonne idée
>
>
> Tout à fait. Mais XML a aussi des défauts, je pense. Par exemple,
> les IDREFS. À moins que l'on considère que des noms séparés par
> des espaces forment en quelque sorte une liste. Mais ça ne se gère
> pas très bien par XSLT. C'est dommage. Idem pour les PI, dont la
> forme est assez libre, mais qui peuvent être construites comme des
> éléments, auquel cas il faut un parseur particulier pour parser
> les pseudo-attributs (ou j'ai manqué quelque chose?).
>
non, je suis complètement d'accord : xml a aussi ses défauts, n'oublions
pas qu'il a été construit sur sgml, et à mon avis, il n'a pas été assez
épuré
mais bon, on va pas refaire le monde :) et puis c'est facile de
critiquer 6 ans après
cela dit, j'en profite pour rebondir sur les pi qui soulèvent d'autres
problèmes : on ne peut pas les imbriquer, il peut y avoir des conflits
de noms, ils ne peuvent être contraints par une grammaire...
tout ça pour dire que si on a besoin d'une structure de données qui
représente qq chose d'actif pour une application, alors autant utiliser
un élément avec un bon vieux namespace plutôt qu'une pi
Vincent Lefevre
Philippe Poulard <Philippe....@spamsophia.inria.fr> écrit:
> tout ça pour dire que si on a besoin d'une structure de données qui
> représente qq chose d'actif pour une application, alors autant utiliser
> un élément avec un bon vieux namespace plutôt qu'une pi
Oui, mais le problème est qu'il faut alors changer la DTD, et que
s'il s'agit d'une DTD standard, ce n'est pas terrible. Il faudrait
que ce soit standardisé, du genre un élément xml:pi avec un attribut
du style xml:name et éventuellement d'autres attributs (enfin, les
données supplémentaires pourraient être mises en fils du xml:pi), et
que les DTD prennent en compte un tel élément standard. Est-ce que
cela serait une bonne chose?
Philippe Poulard
> Dans l'article <c55kk2$so1$1...@news-sop.inria.fr>,
> Philippe Poulard <Philippe....@spamsophia.inria.fr> écrit:
>
>
>>tout ça pour dire que si on a besoin d'une structure de données qui
>>représente qq chose d'actif pour une application, alors autant utiliser
>>un élément avec un bon vieux namespace plutôt qu'une pi
>
>
> Oui, mais le problème est qu'il faut alors changer la DTD, et que
> s'il s'agit d'une DTD standard, ce n'est pas terrible.
pas du tout : ça permet au contraire de contraindre une structure qui ne
l'était pas et qui ne peut l'être en l'état
les dtd standard peuvent évoluer; les dtd modulaires sont plus adaptées
pour absorber des contraintes
là où ça pose problème, c'est dans un mode de contrainte "lâche" dans
lequel on accepte qq chose sans savoir ce que c'est; il faut reconnaître
que les dtd sont larguées à ce niveau : ANY signifie tout élément connu
:( peut-être que WXS ou Relax NG sont plus adaptés (RNG oui pour WXS je
sais pas) ?
Il faudrait
> que ce soit standardisé, du genre un élément xml:pi avec un attribut
> du style xml:name et éventuellement d'autres attributs (enfin, les
> données supplémentaires pourraient être mises en fils du xml:pi), et
> que les DTD prennent en compte un tel élément standard. Est-ce que
> cela serait une bonne chose?
>
c'est déjà standardisé par les éléments et les espaces de nommage; si on
écrit xml:pi on améliore la structure mais on déplace le problème des
conflits de nom; autant utiliser des éléments
rriv
> Philippe Poulard wrote:
>
> >
> > avec ce type de structures, on est obligé :
> > -d'utiliser un parseur xml
> > -d'écrire un parseur non xml qui parse les données de chaque ligne
> >
> > foutu pour foutu, autant laisser tomber xml
> > ...ou adopter complètement xml, et pour moi ça signifie coder des
> > données atomiques, donc :
> >
>
et Franck Guillaud <f_point_...@free.fr> répondit :
> Je suis d'accord avec toi, mais c'est pourtant le choix qui a été fait
> pour SVG. En effet les polylignes ne sont pas codées de manières "atomique".
>
Ahah, discussion très intéressante.
Mon interprétation à moi est que, pour certains domaines particuliers, ça devient
intéressant d'avoir une structure XML englobante, avec des morceaux non-XML dedans.
C'est le cas de SVG effectivement, et c'est la proposition qui est faite dans ce thread
pour représenter les lignes d'un tableau.
Et partant du constat que c'est un "problème fréquemment rencontré", "on" développe
des composants pour gérer les morceaux non-XML de manière la plus cohérente possible.
Ca a été fait pour SVG, pourquoi ça ne serait pas faisable les lignes de tableau ?
Ca correpondrait en fait à un espèce de XML-CSV. Les valeurs seraient à la syntaxe CSV,
et on enroberait ça dans des balises XML apportant de la sémantique sur les lignes et colonnes.
Robert
Philippe Poulard
ce qui me gêne c'est le parseur dans le parseur; si on trouve que c'est
utile, alors autant le standardiser... et mettre à jour le dom avec des
méthodes comme getCSVList par exemple ? le problème est de trouver les
bonnes structures...
wxs propose un type "liste" pas vraiment configurable car seul le blanc
est prévu comme séparateur mais on peut faire avec
il y a aussi le org.w3c.dom.TypeInfo objet qui pourra servir
Fabrice
<vincen...@vinc17.org> wrote :
> > Je suis allé voir ce format MathML mais il me semble à priori lourd
> > pour mon utilisation. Par exemple pour représenter une matrice,
> > chaque cellule doit être entouré d'une balise,
>
> C'est pourtant la seule solution, sinon tu perds tout l'intérêt du
> XML.
>
> > j'imagine la perte de performance pour parser une grosse matrice !
>
> Tout dépend de ton application. Bien souvent, parser prend peu de
> temps car il y a tout un traitement derrière. À toi de voir...
Ok argument imparable. Cela donne effectivement à réfléchir...
> > Est-ce qu'on ne peut pas imaginer quelque chose comme :
> > <ligne> a1 b1 c1 d1 <\ligne>
> > <ligne> a2 b2 c2 d2 <\ligne>
> > ...
> > <ligne> an bn cn dn <\ligne>
>
> Dans ce cas autant oublier XML.
>
> Au fait, pourquoi veux-tu utiliser XML?
>
Disons que je souhaite utiliser un format de fichier plus ouvert que
celui que j'utilisais auparavant tout en gardant les mêmes
fonctionnalités et les mêmes performances. Mais bon je suppose que je ne
peux pas avoir le beurre et l'argent du beurre et qu'il va me falloir
faire une concession sur les performances, après tout pourquoi pas ?
Pour information, je souhaite exploiter un document XML à partir d'un
programme en C.
Plus techniquement je dois initialiser des matrices à partir de ces
matrices contenues dans un document formaté XML.
Fabrice
<xav...@editions-oreilly.fr> wrote :
Non je pense que les gens de ce forum ont raison. La priorité n'est pas
la performance en vitesse mais l'interopérabilité avec l'extérieur. Les
machines évoluent beaucoup plus vite que les logiciels développés par
une entreprise donc il serait dommage de perdre en souplesse pour des
raisons de vitesse.
Je vais tenter ma chance avec MathML.
Je me permets de vous poser la même question qu'aux autres : auriez-vous
un parseur XML pour la langage C à me conseiller ? Et un logiciel
pouvant tracer des courbes (2D ou 3D) à partir de fichier au format
MathML ?
Merci d'avance !
Fabrice
<Philippe....@SPAMsophia.inria.fr> wrote :
> > Je suis allé voir ce format MathML mais il me semble à priori lourd
> > pour mon utilisation. Par exemple pour représenter une matrice,
> > chaque cellule doit être entouré d'une balise, j'imagine la perte de
> > performance pour parser une grosse matrice !
>
> peut-être que MathML est trop général pour ton problème très
> spécifique, et en effet, une structure sur mesure est plus adaptée; on
> peut tout avec xml.
>
> > mais peut-être est-ce une
> > limitation de XML ?
>
> il faut savoir ce qu'on veut : faire du xml et dans ce cas utiliser un
> analyseur xml et bénéficier de tout l'apport de ce type d'outil :
> support de l'unicode, obtention d'un modèle de données, faible
> sensibilité à l'évolution, découplage des données/applis, etc...
>
> ou alors on utilise un super programme qu'on fait soit-même, et on
> réinvente la roue, et elle ne sera pas aussi ronde que ça mais
> tournera peut-être un peu plus vite; peut-être que perl est un
> candidat potentiel pour ton problème ?
En fait le choix du langage qui exploitera le document XML est déjà
fait, ce sera du C (mais bon je suppose qu'il existe des parseurs XML
dans tous les langages maintenant).
Je souhaitais surtout utiliser un nouveau format de données plus ouvert
que celui que j'utilisais tout en gardant les mêmes fonctionnalités. Le
problème de perfomance est, après réflexion, secondaire.
Ok je vais faire quelques tests. Les performances en vitesse sont
relativement secondaires, si je perds 50 ou 80% ce n'est pas grave. Par
contre si je passe à un facteur 10 ou 100 c'est une autre histoire (je
manipule des matrices de l'ordre de 1 Go...).
J'avais développé mon propre parseur spécifique à mon ancien format de
donnée et je suis assez curieux de voir comment il se comporte par
rapport aux parseurs XML codé par des pros... ;-)
Pour information je cherche des parseurs pour le langage C. Ce parseur
doit pouvoir lire des entiers/réels/chaînes de caractères/booléens (bref
les types standards du C) en effectuant un contrôle d'erreur très
rigoureux (par exemple si on essaye de prendre un entier et que celui-ci
dépasse 32768 il doit y avoir un message d'erreur explicite).
D'ailleurs : qu'est-ce qui différencie les différents parseurs
disponibles sur la marché ?
> >
> > Je précise de nouveau que je suis novice en XML, désolé si je
> > profère des énormités...
>
> du tout, il faut bien commencer un jour
>
> bon, j'ai essayé d'être neutre dans ma réponse : le choix
> t'appartient, mais choisi full xml ou pas du tout xml, mais pas de
> compromis !
Ok je vais tenter ma chance avec l'XML et plus particulièrement MathML
Et dernière question : auriez-vous un logiciel tracant des courbes à
partir de fichiers MathML à me recommander ?
Merci !
Vincent Lefevre
Fabrice <non_v...@yahoo.fr> écrit:
> On Thu, 8 Apr 2004 07:48:46 +0000 (UTC), Vincent Lefevre
> <vincen...@vinc17.org> wrote :
> > Au fait, pourquoi veux-tu utiliser XML?
> Disons que je souhaite utiliser un format de fichier plus ouvert que
> celui que j'utilisais auparavant tout en gardant les mêmes
> fonctionnalités et les mêmes performances.
XML n'est pas spécialement ouvert. D'ailleurs, tu peux tout mettre
dans un élément root et tu n'es pas plus avancé. L'intérêt de XML
est de pouvoir structurer ses documents sous forme d'arbre et faire
des manipulations avec des outils standards. Alors pourquoi faire
les choses à moitié et mettre une suite de nombres dans un seul
noeud texte au lieu de les séparer à l'aide d'éléments?
> Mais bon je suppose que je ne peux pas avoir le beurre et l'argent
> du beurre et qu'il va me falloir faire une concession sur les
> performances, après tout pourquoi pas ?
Si tu vois une différence au niveau des performances, ça risque d'être
aussi le cas par rapport à un format tout simple style CSV.
> Pour information, je souhaite exploiter un document XML à partir d'un
> programme en C.
> Plus techniquement je dois initialiser des matrices à partir de ces
> matrices contenues dans un document formaté XML.
Si tu vas faire des calculs avec ces matrices, je pense que le
parsage XML sera négligeable.
Autre chose, si les coefficients des matrices sont des nombres de
plusieurs chiffres, stocke-les dans une représentation hexadécimale,
sinon tu vas perdre du temps à la conversion base 10 -> base 2. :)
Je pense que tu risques de perdre plus de temps sur une telle
conversion que pour le parsage XML avec un parseur suffisamment
bien optimisé (SAX pourrait être une solution).
--
Vincent Lefèvre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Fabrice
<vincen...@vinc17.org> wrote :
> > > Au fait, pourquoi veux-tu utiliser XML?
>
> > Disons que je souhaite utiliser un format de fichier plus ouvert que
> > celui que j'utilisais auparavant tout en gardant les mêmes
> > fonctionnalités et les mêmes performances.
>
> XML n'est pas spécialement ouvert. D'ailleurs, tu peux tout mettre
> dans un élément root et tu n'es pas plus avancé. L'intérêt de XML
> est de pouvoir structurer ses documents sous forme d'arbre et faire
> des manipulations avec des outils standards. Alors pourquoi faire
> les choses à moitié et mettre une suite de nombres dans un seul
> noeud texte au lieu de les séparer à l'aide d'éléments?
Oui, oui je comprends bien l'argument maintenant...
>
> > Mais bon je suppose que je ne peux pas avoir le beurre et l'argent
> > du beurre et qu'il va me falloir faire une concession sur les
> > performances, après tout pourquoi pas ?
>
> Si tu vois une différence au niveau des performances, ça risque d'être
> aussi le cas par rapport à un format tout simple style CSV.
Pas sûr, pour avoir développé le parseur d'un CSV (c'est bien Comma
Separated Values ?), j'ai l'impression que plus la forme du séparateur
est compliquée (et plus il y a de séparateurs possibles) plus la mise en
place du parseur est lourde.
Par exemple (du moins pour le C) il est plus facile pour moi de parser :
123.456-456.789-321.654 avec '-' comme séparateur
que :
<zorglub> 123.456 <\zorglub>
<aoige> 456.789 <\aoige>
<teroitu> 321.654 <\teroitu>
Bien sûr dans le deuxième cas on ajoute beaucoup plus de signification
aux valeurs...
> > Pour information, je souhaite exploiter un document XML à partir
> > d'un programme en C.
> > Plus techniquement je dois initialiser des matrices à partir de ces
> > matrices contenues dans un document formaté XML.
>
> Si tu vas faire des calculs avec ces matrices, je pense que le
> parsage XML sera négligeable.
Pas forcément, les matrices en entrées et en sorties sont gigantesques
et les opérations relativement simples. De plus pour des contraintes de
souplesse dans le code il arrive que l'on lise plusieurs fois (par
exemple 10 fois) la même matrice (car c'est trop compliqué de la garder
en mémoire). Mais bon il est clair que le code peut être optimisé mais
là n'est pas trop la question... Je suis d'accord sur le principe de
perdre du temps à la lecture/écriture si ça me permet de gagner en
souplesse !
> Autre chose, si les coefficients des matrices sont des nombres de
> plusieurs chiffres, stocke-les dans une représentation hexadécimale,
> sinon tu vas perdre du temps à la conversion base 10 -> base 2. :)
Euh là je n'ai pas trop compris.
Les coefficients de la matrice sont principalement des réels.
Apparemment tu es un expert en C donc je peux détailler : avec l'ancien
format je faisais un coup de 'strtod' et je stockais le résultat dans un
réel avant de faire les opérations, ce n'est pas ce qu'il faut faire ?
Je ne vois pas très bien où intervient la représentation hexadécimale
(ou même le coup de la base 10 !??)
> Je pense que tu risques de perdre plus de temps sur une telle
> conversion que pour le parsage XML avec un parseur suffisamment
> bien optimisé (SAX pourrait être une solution).
Ok je vais faire le test dès que possible.
Au fait quelle est la différence entre DOM et SAX ?
Merci !
Vincent Lefevre
Fabrice <non_v...@yahoo.fr> écrit:
> On Sat, 10 Apr 2004 00:01:43 +0000 (UTC), Vincent Lefevre
> <vincen...@vinc17.org> wrote :
> > Si tu vois une différence au niveau des performances, ça risque d'être
> > aussi le cas par rapport à un format tout simple style CSV.
> Pas sûr, pour avoir développé le parseur d'un CSV (c'est bien Comma
> Separated Values ?), j'ai l'impression que plus la forme du séparateur
> est compliquée (et plus il y a de séparateurs possibles) plus la mise en
> place du parseur est lourde.
J'ai dit "style CSV". Tu peux choisir ton séparateur... Mais tu aurais
le même genre de problèmes en mettant plusieurs nombres dans un seul
noeud texte en XML.
> Par exemple (du moins pour le C) il est plus facile pour moi de parser :
> 123.456-456.789-321.654 avec '-' comme séparateur
... jusqu'au jour où tu t'aperçois que tu veux représenter des nombres
négatifs (cela m'est arrivé).
> que :
> <zorglub> 123.456 <\zorglub>
> <aoige> 456.789 <\aoige>
> <teroitu> 321.654 <\teroitu>
Tu peux simplement faire:
<table>
<tr><td>1.2</td><td>3.4</td></tr>
<tr><td>5.6</td><td>7.8</td></tr>
</table>
L'essentiel est d'avoir une cohésion dans le nom de ses éléments.
La forme suivante est peut-être meilleure:
<v>
<v><r>1.2</r><r>3.4</r></v>
<v><r>5.6</r><r>7.8</r></v>
</v>
où v sert à définir un vecteur (une matrice étant un vecteur de
vecteurs) et r un réel.
> > Si tu vas faire des calculs avec ces matrices, je pense que le
> > parsage XML sera négligeable.
> Pas forcément, les matrices en entrées et en sorties sont gigantesques
> et les opérations relativement simples.
Un parsage par SAX est très simple aussi (mais je n'ai jamais essayé).
> De plus pour des contraintes de souplesse dans le code il arrive que
> l'on lise plusieurs fois (par exemple 10 fois) la même matrice (car
> c'est trop compliqué de la garder en mémoire).
C'est peut-être mieux de stocker une version binaire (temporaire) sur
disque dans ces cas-là (avec possibilité d'utiliser mmap).
> Mais bon il est clair que le code peut être optimisé mais là n'est
> pas trop la question... Je suis d'accord sur le principe de perdre
> du temps à la lecture/écriture si ça me permet de gagner en
> souplesse !
C'est peut-être le temps de lecture du fichier. Tu as un overhead de
7 caractères (en prenant des éléments à 1 caractère) au lieu de 1 avec
un format style CSV.
> > Autre chose, si les coefficients des matrices sont des nombres de
> > plusieurs chiffres, stocke-les dans une représentation hexadécimale,
> > sinon tu vas perdre du temps à la conversion base 10 -> base 2. :)
> Euh là je n'ai pas trop compris.
> Les coefficients de la matrice sont principalement des réels.
Raison de plus.
> Apparemment tu es un expert en C donc je peux détailler : avec
> l'ancien format je faisais un coup de 'strtod' et je stockais le
> résultat dans un réel avant de faire les opérations, ce n'est pas ce
> qu'il faut faire ? Je ne vois pas très bien où intervient la
> représentation hexadécimale (ou même le coup de la base 10 !??)
strtod fait une conversion d'un nombre écrit en base 10 (sous forme de
chaîne) en un nombre représenté en binaire. En interne, cela te fait
pas mal d'opérations flottantes. Si en plus tu as un exposant (e.g.
1.2e60), c'est pire...
> Au fait quelle est la différence entre DOM et SAX ?
DOM, c'est une interprétation sous forme d'arbre. SAX, c'est une
vision plutôt linéaire (à un plus bas niveau), et cela permet d'être
plus économe en mémoire. Pour initialiser des matrices, je pense que
SAX conviendrait parfaitement.
Vincent Lefevre
Fabrice <non_v...@yahoo.fr> écrit:
> Non je pense que les gens de ce forum ont raison. La priorité n'est pas
> la performance en vitesse mais l'interopérabilité avec l'extérieur. Les
> machines évoluent beaucoup plus vite que les logiciels développés par
> une entreprise donc il serait dommage de perdre en souplesse pour des
> raisons de vitesse.
> Je vais tenter ma chance avec MathML.
Tu peux imposer un sous-ensemble de MathML. En gros, ton programme
verra ça comme un format particulier (plus simple que MathML), et tu
pourras utiliser les mêmes fichiers dans des applications acceptant
le MathML en entrée.
> Je me permets de vous poser la même question qu'aux autres :
> auriez-vous un parseur XML pour la langage C à me conseiller ?
Je ne sais pas. libxml a une interface SAX, mais je ne sais pas s'il y
en a de meilleures (expat?).
> Et un logiciel pouvant tracer des courbes (2D ou 3D) à partir de
> fichier au format MathML ?
Aucune idée. Note: "format MathML" est plutôt vague et ça pourra être
interprété différemment par divers logiciels.
Fabrice
<vincen...@vinc17.org> wrote :
> > > Autre chose, si les coefficients des matrices sont des nombres de
> > > plusieurs chiffres, stocke-les dans une représentation
> > > hexadécimale, sinon tu vas perdre du temps à la conversion base 10
> > > -> base 2. :)
>
> > Euh là je n'ai pas trop compris.
> > Les coefficients de la matrice sont principalement des réels.
>
> Raison de plus.
>
> > Apparemment tu es un expert en C donc je peux détailler : avec
> > l'ancien format je faisais un coup de 'strtod' et je stockais le
> > résultat dans un réel avant de faire les opérations, ce n'est pas ce
> > qu'il faut faire ? Je ne vois pas très bien où intervient la
> > représentation hexadécimale (ou même le coup de la base 10 !??)
>
> strtod fait une conversion d'un nombre écrit en base 10 (sous forme de
> chaîne) en un nombre représenté en binaire. En interne, cela te fait
> pas mal d'opérations flottantes. Si en plus tu as un exposant (e.g.
> 1.2e60), c'est pire...
Ah ! je viens de comprendre !
On avait aussi pensé à stocker les fichiers sous forme binaires, mais
cela induisait trop de contrainte. Donc on est resté en mode texte. Par
contre on avait pas pensé à la représentation hexadécimale...
il faudrait que je fasse un 'profilage' pour voir si c'est 'strtod' qui
prend effectivement le plus de temps dans le processus de
parsage/décodage/affectation.
> > Au fait quelle est la différence entre DOM et SAX ?
>
> DOM, c'est une interprétation sous forme d'arbre. SAX, c'est une
> vision plutôt linéaire (à un plus bas niveau), et cela permet d'être
> plus économe en mémoire. Pour initialiser des matrices, je pense que
> SAX conviendrait parfaitement.
>
Ok je vais faire un test.
Merci !
Fabrice
<vincen...@vinc17.org> wrote :
> > Non je pense que les gens de ce forum ont raison. La priorité n'est
> > pas la performance en vitesse mais l'interopérabilité avec
> > l'extérieur. Les machines évoluent beaucoup plus vite que les
> > logiciels développés par une entreprise donc il serait dommage de
> > perdre en souplesse pour des raisons de vitesse.
> > Je vais tenter ma chance avec MathML.
>
> Tu peux imposer un sous-ensemble de MathML. En gros, ton programme
> verra ça comme un format particulier (plus simple que MathML), et tu
> pourras utiliser les mêmes fichiers dans des applications acceptant
> le MathML en entrée.
D'accord. Cependant il y a une chose que je n'ai pas compris et qui
reste encore plus obscur après avoir jeté un oeil sur libxml et SAX :
apparemment l'avantage du XML est d'avoir un DTD qui explique à quoi
correspond les balises dans le document XML. Dans ce cas quel est
l'intérêt d'utiliser MathML puisque n'importe quel format XML
conviendrait ? Est-ce que c'est juste pour éviter de construire un DTD
spécifique ?
> > Je me permets de vous poser la même question qu'aux autres :
> > auriez-vous un parseur XML pour la langage C à me conseiller ?
>
> Je ne sais pas. libxml a une interface SAX, mais je ne sais pas s'il y
> en a de meilleures (expat?).
Oui si on pouvait m'indiquer la meilleure tout de suite, ça
m'arrangerait ;-) !
Mais bon je suppose que pour un novice comme moi les différences sont
trop subtiles...
> > Et un logiciel pouvant tracer des courbes (2D ou 3D) à partir de
> > fichier au format MathML ?
>
> Aucune idée. Note: "format MathML" est plutôt vague et ça pourra être
> interprété différemment par divers logiciels.
>
Voir plus haut, mais il me semblait qu'à partir du moment où un logiciel
pouvait lire du XML il pouvait aussi bien lire du MathML ou n'importe
quel document XML.
Donc la question est peut être : existe-t-il un logiciel pouvant tracer
des courbes à partir de fichier au format XML ?
Fabrice
<vincen...@vinc17.org> wrote :
> > Je me permets de vous poser la même question qu'aux autres :
> > auriez-vous un parseur XML pour la langage C à me conseiller ?
>
> Je ne sais pas. libxml a une interface SAX, mais je ne sais pas s'il y
> en a de meilleures (expat?).
>
Allons bon, en faisant quelques recherches il apparaît que l'on me
déconseille d'utiliser SAX :
http://mail.gnome.org/archives/xml/2003-January/msg00192.html
http://xmlsoft.org/xmlreader.html
Je commence un peu à me perdre dans la jungle d'internet...
Vincent Lefevre
Fabrice <non_v...@yahoo.fr> écrit:
> D'accord. Cependant il y a une chose que je n'ai pas compris et qui
> reste encore plus obscur après avoir jeté un oeil sur libxml et SAX :
> apparemment l'avantage du XML est d'avoir un DTD qui explique à quoi
> correspond les balises dans le document XML.
Oui, mais pas uniquement. Tu as également d'autres formes de validation
(schémas...).
> Dans ce cas quel est l'intérêt d'utiliser MathML puisque n'importe
> quel format XML conviendrait ?
De pouvoir passer tes matrices directement à n'importe quel programme
comprenant le MathML. L'intérêt est peut-être limité. À toi de voir...
> Est-ce que c'est juste pour éviter de construire un DTD spécifique ?
Définir une DTD pour des matrices est tout ce qu'il y a de plus
simple. :)
> Voir plus haut, mais il me semblait qu'à partir du moment où un logiciel
> pouvait lire du XML il pouvait aussi bien lire du MathML ou n'importe
> quel document XML.
Oui, mais tout le problème revient ensuite à interpréter les données.
> Donc la question est peut être : existe-t-il un logiciel pouvant
> tracer des courbes à partir de fichier au format XML ?
Je ne sais pas.
Vincent Lefevre
Fabrice <non_v...@yahoo.fr> écrit:
> Allons bon, en faisant quelques recherches il apparaît que l'on me
> déconseille d'utiliser SAX :
Une chose est claire: SAX, c'est du bas niveau. Dès que tu veux faire
des choses suffisamment compliquées, ce n'est probablement pas la
meilleure solution.
> http://mail.gnome.org/archives/xml/2003-January/msg00192.html
Là il est question d'entités. Ça ne te concerne probablement pas
(refuse explicitement les entités dans tes spécifications).
> http://xmlsoft.org/xmlreader.html
Évidemment, SAX n'est pas la seule solution. À toi de voir si
XmlTextReader peut te convenir.