> Et je réponds à nouveau que si tu cherches la récursivité, tu utilises
> des noeuds (donc des balises). D'un point de vue temps de
> définition, c'est à peu près équivalent (avec une DTD).
C'est un peu un probleme. Surtout que les noeuds sont fait pour etre un conteneur et non expliciter le noeud lui-même. Par exemple, dans une interface graphique, je peux assigner des signaux aux éléments graphiques sous forme d'attribut et mettre d'autres éléments graphiques dedans. Si je passe mes atributs sous forme de noeud, je peux avoir des clash avec les noeuds qui sont déjà la.
Il est vrai que si les attributs deviennent des arbres a part entière, la ligne de démarcation attribut/noeud sera moins claire, ce sera au schema de la préciser. Mais au moins on aura une double structure symétrique ayant une API propre laissant le développeur s'exprimer.
> Euh non. :-)
T'as raison, j'avais mal saisie la dynamique de la phrase.
Pour la suite, je suis d'accord que le développement du XML texte a dynamiser, popularisé, révolutionné (...) le développpement de librairies de recherche dans les arbres. et je trouve ca TRES BIEN. C'est le XML texte que je n'aime pas.
> XML, dans sa forme « écrite » n'a rien à voir avec ce qu'est XML
> fondamentalement.
Tu vois, on est d'accord ;-) Sauf que moi, le XML fondamentalement, je l'appelle arbre. Même que parfois, on est limité et on a la structure de graphe qui est pas mal et ce serait bien si elle profitait de la même énergie que les arbres.
> on s'en fiche un peu.
Malheureusement non. La mode Tomcat est au fichier de conf imbittable. Tu prends les fichiers de conf des modules Perl sur le CPAN, du beau YAML, c'est que du bonheur.
> NB : en TeX/LaTeX, tu as aussi des attributs, qui ne sont pas
> récursifs non plus, et qui - surprise ! - sont non ordonnés :
Attention, TeX est reprogrammable ! Si LaTeX avait eu la même énergie mise dessus que le XML, on aurait une API tip-top. Je sais qu'il y a des problèmes avec TeX mais regardes le nombre de personnes qui sont dessus. C'est quand même impressionant pour ce résultat.
> Si tu continues comme ça, tu pourrais dire qu'à part XSL/T, les
> langages de transformation de XML ne ressemblent pas trop à du
> XML.
Justement, je continue. C'est pour cela que je parle de fatras. Au moins, en TeX, tu programmes en TeX ;-)
> Et après ? XML est fait pour être lu par des machines.
Encore une fois, je suis d'accord. Mais autant prendre alors un format binaire. C'est bien plus performant. Si mes souvenirs sont bon, le format HDF est tout a fait capable de stocker un arbre XML de manière portable.
Bref, ca montre encore une fois qu'il y a un réel problème de conception, et qu'on a pour longtemps.
> D'ailleurs, XSL/T, ça a beau être super puissant, c'est tellement
> chiant à utiliser que dès que je peux éviter ben... j'évite :-)
J'avais pas osé en parlé mais comme horreur, c'est merveilleux. Dire que j'ai croisé des personnes qui ont critiqué mes Makefile sur des arguments fallacieux (en gros, c'est pas sexy ! Bon ok, la syntaxe des Makefiles a aussi des defauts). Le XSLT, c'est vraiment poussé le XML sur une mauvaise voie et ca montre clairement les limites de la syntaxe. Limite qu'on aurait pas eu avec une syntaxe de type LISP.
D'ailleurs, avec AxKit, tu peux faire des filtres en XSLT ou en XPS (XpathScript, un savant mélange de Perl et de XPath). Et bien, j'ai fait quasiment tous mes filtres en XPS ;-) Le seul défaut, c'est pas portable, le XPS n'ayant jamais percé en dehors de AxKit (dommage).
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
> des noeuds (donc des balises). D'un point de vue temps de
> définition, c'est à peu près équivalent (avec une DTD).
C'est un peu un probleme. Surtout que les noeuds sont fait pour etre un conteneur et non expliciter le noeud lui-même. Par exemple, dans une interface graphique, je peux assigner des signaux aux éléments graphiques sous forme d'attribut et mettre d'autres éléments graphiques dedans. Si je passe mes atributs sous forme de noeud, je peux avoir des clash avec les noeuds qui sont déjà la.
Il est vrai que si les attributs deviennent des arbres a part entière, la ligne de démarcation attribut/noeud sera moins claire, ce sera au schema de la préciser. Mais au moins on aura une double structure symétrique ayant une API propre laissant le développeur s'exprimer.
> Euh non. :-)
T'as raison, j'avais mal saisie la dynamique de la phrase.
Pour la suite, je suis d'accord que le développement du XML texte a dynamiser, popularisé, révolutionné (...) le développpement de librairies de recherche dans les arbres. et je trouve ca TRES BIEN. C'est le XML texte que je n'aime pas.
> XML, dans sa forme « écrite » n'a rien à voir avec ce qu'est XML
> fondamentalement.
Tu vois, on est d'accord ;-) Sauf que moi, le XML fondamentalement, je l'appelle arbre. Même que parfois, on est limité et on a la structure de graphe qui est pas mal et ce serait bien si elle profitait de la même énergie que les arbres.
> on s'en fiche un peu.
Malheureusement non. La mode Tomcat est au fichier de conf imbittable. Tu prends les fichiers de conf des modules Perl sur le CPAN, du beau YAML, c'est que du bonheur.
> NB : en TeX/LaTeX, tu as aussi des attributs, qui ne sont pas
> récursifs non plus, et qui - surprise ! - sont non ordonnés :
Attention, TeX est reprogrammable ! Si LaTeX avait eu la même énergie mise dessus que le XML, on aurait une API tip-top. Je sais qu'il y a des problèmes avec TeX mais regardes le nombre de personnes qui sont dessus. C'est quand même impressionant pour ce résultat.
> Si tu continues comme ça, tu pourrais dire qu'à part XSL/T, les
> langages de transformation de XML ne ressemblent pas trop à du
> XML.
Justement, je continue. C'est pour cela que je parle de fatras. Au moins, en TeX, tu programmes en TeX ;-)
> Et après ? XML est fait pour être lu par des machines.
Encore une fois, je suis d'accord. Mais autant prendre alors un format binaire. C'est bien plus performant. Si mes souvenirs sont bon, le format HDF est tout a fait capable de stocker un arbre XML de manière portable.
Bref, ca montre encore une fois qu'il y a un réel problème de conception, et qu'on a pour longtemps.
> D'ailleurs, XSL/T, ça a beau être super puissant, c'est tellement
> chiant à utiliser que dès que je peux éviter ben... j'évite :-)
J'avais pas osé en parlé mais comme horreur, c'est merveilleux. Dire que j'ai croisé des personnes qui ont critiqué mes Makefile sur des arguments fallacieux (en gros, c'est pas sexy ! Bon ok, la syntaxe des Makefiles a aussi des defauts). Le XSLT, c'est vraiment poussé le XML sur une mauvaise voie et ca montre clairement les limites de la syntaxe. Limite qu'on aurait pas eu avec une syntaxe de type LISP.
D'ailleurs, avec AxKit, tu peux faire des filtres en XSLT ou en XPS (XpathScript, un savant mélange de Perl et de XPath). Et bien, j'ai fait quasiment tous mes filtres en XPS ;-) Le seul défaut, c'est pas portable, le XPS n'ayant jamais percé en dehors de AxKit (dommage).