« Le XML est à la mode mais il a aussi ses défauts. »
Jusque là, je suis tout à fait d'accord. :-)
« Très verbeux, "chiant" à deboguer à la main... »
Euh oui, mais n'oublie pas un truc que tu as dit en tout premier, en haut de ton post : « Le XML est conçu pour la machine » !
« Il souffre surtout à mon avis d'une erreur de conception au niveau des attributs. En effet, il perds l'aspect récursif du LISP a ce niveau là, les attributs étant des chaines de textes entre "" et non du XML »
Là-dessus, je ne suis pas d'accord. Premièrement, si vraiment tu tiens à ne pas utiliser les attributs, tu n'as qu'à définir une balise « vide », dire quelle autre balise peut l'utiliser, et c'est fini (exemple pour XHTML : <br/>).
Deuxièmement, il faut voir les documents XML comme des arbres, dont les noeuds peuvent posséder, en plus de leurs enfants et de l'étiquette qui les identifie, une séquence de données supplémentaires : les attributs. Là où un document XML est un arbre ordonné, les attributs ont l'avantage de plutôt représenter un « ensemble » de données (non ordonnées, donc). Suivant l'usage dont tu as besoin, ça peut être très pratique. Par exemple, je trouve bien plus utile d'avoir une balise « vide » <date/>, avec comme obligation de comporter au moins un attribut « année » et comme attributs optionnels « mois » et « jour », que de définir la même balise comme étant composée de trois autres balises :
<!ELEMENT date (annee, mois?, jour?)>
De toute manière, on se fiche un peu de l'ordre dans lequel ils apparaissent, non ?
Si tu as besoin de l'aspect récursif des types XML, tu utilises les balises ; sinon, tu as le choix entre attributs et balises suivant que tu désires sous-typer ou pas ta structure de données.
« Bilan, il y a tout un tas d'API pour contourner ce problème de conception, »
Euh, tu dis que les API sont là pour contourner le fait que les attributs existent ? Ca me semble un peu irréel comme remarque, ça ! :-)
A moins d'utiliser les ID-REFs dans tes schémas XML, les documents XML sont strictement des arbres. Pas de risque de cycle, rien. Il y a tout plein de problèmes qui risquent de se poser pour faire l'analyse de docs XML, mais certainement pas les attributs !
« Le plus grave, c'est qu'on en a pris pour 20 ou 30 ans et que ca va nous faire chie... »
Meuh non. Premièrement, définir une DTD c'est chiant, mais ça n'a rien d'impossible (et c'est surtout ça le problème avec XML je trouve : le fait que les gens ne prennent pas la peine de définir correctement des DTD ou des schémas XML). Ensuite, il existe des outils pour exporter une DTD en schéma XML (car les DTD ont certaines limitations, mais sont, en contrepartie, relativement lisibles, comparées aux schémas XML).
Enfin, pour ceux qui l'ignoreraient, il existe un langage de requête, XQuery, qui possède déjà quelques implémentations, et qui a le gros avantage de prendre en compte le fait qu'un document XML est typé, et donc ne fait pas de recherche stupide lorsqu'il peut l'éviter.
Le XML est là en partie pour permettre de modéliser des choses qui le sont difficilement avec des systèmes de gestion de bases de données classiques (notamment relationnelles), ou bien au prix de certaines contorsions ou d'occupation excessive de la mémoire.
« Je ne suis pas programmeur et fanatique de LISP mais avec une syntaxe bien plus simple et récusive, tu refais tout XML en propre. »
Bof. Les données semi-structurées, ça fait un bout de temps que ça existe, sauf qu'avant, chacun avait son modèle dans son coin. Ce qu'apporte XML, c'est un compromis entre différents acteurs du monde industriel (Microsoft, Sun, etc.) et scientifiques (universités, INRIA, etc). Comme tous les compromis, il n'est pas parfait, car chacun voulait que « sa » killer-feature se retrouve dans le langage. Mais franchement, on n'en est qu'au début de l'exploitation d'XML. Laissez encore cinq ans aux différents acteurs pour élaborer des méthodes d'interrogation efficaces de XML, et on en reparlera.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par lasher . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
Jusque là, je suis tout à fait d'accord. :-)
« Très verbeux, "chiant" à deboguer à la main... »
Euh oui, mais n'oublie pas un truc que tu as dit en tout premier, en haut de ton post : « Le XML est conçu pour la machine » !
« Il souffre surtout à mon avis d'une erreur de conception au niveau des attributs. En effet, il perds l'aspect récursif du LISP a ce niveau là, les attributs étant des chaines de textes entre "" et non du XML »
Là-dessus, je ne suis pas d'accord. Premièrement, si vraiment tu tiens à ne pas utiliser les attributs, tu n'as qu'à définir une balise « vide », dire quelle autre balise peut l'utiliser, et c'est fini (exemple pour XHTML : <br/>).
Deuxièmement, il faut voir les documents XML comme des arbres, dont les noeuds peuvent posséder, en plus de leurs enfants et de l'étiquette qui les identifie, une séquence de données supplémentaires : les attributs. Là où un document XML est un arbre ordonné, les attributs ont l'avantage de plutôt représenter un « ensemble » de données (non ordonnées, donc). Suivant l'usage dont tu as besoin, ça peut être très pratique. Par exemple, je trouve bien plus utile d'avoir une balise « vide » <date/>, avec comme obligation de comporter au moins un attribut « année » et comme attributs optionnels « mois » et « jour », que de définir la même balise comme étant composée de trois autres balises :
<!ELEMENT date (annee, mois?, jour?)>
De toute manière, on se fiche un peu de l'ordre dans lequel ils apparaissent, non ?
Si tu as besoin de l'aspect récursif des types XML, tu utilises les balises ; sinon, tu as le choix entre attributs et balises suivant que tu désires sous-typer ou pas ta structure de données.
« Bilan, il y a tout un tas d'API pour contourner ce problème de conception, »
Euh, tu dis que les API sont là pour contourner le fait que les attributs existent ? Ca me semble un peu irréel comme remarque, ça ! :-)
A moins d'utiliser les ID-REFs dans tes schémas XML, les documents XML sont strictement des arbres. Pas de risque de cycle, rien. Il y a tout plein de problèmes qui risquent de se poser pour faire l'analyse de docs XML, mais certainement pas les attributs !
« Le plus grave, c'est qu'on en a pris pour 20 ou 30 ans et que ca va nous faire chie... »
Meuh non. Premièrement, définir une DTD c'est chiant, mais ça n'a rien d'impossible (et c'est surtout ça le problème avec XML je trouve : le fait que les gens ne prennent pas la peine de définir correctement des DTD ou des schémas XML). Ensuite, il existe des outils pour exporter une DTD en schéma XML (car les DTD ont certaines limitations, mais sont, en contrepartie, relativement lisibles, comparées aux schémas XML).
Enfin, pour ceux qui l'ignoreraient, il existe un langage de requête, XQuery, qui possède déjà quelques implémentations, et qui a le gros avantage de prendre en compte le fait qu'un document XML est typé, et donc ne fait pas de recherche stupide lorsqu'il peut l'éviter.
Le XML est là en partie pour permettre de modéliser des choses qui le sont difficilement avec des systèmes de gestion de bases de données classiques (notamment relationnelles), ou bien au prix de certaines contorsions ou d'occupation excessive de la mémoire.
« Je ne suis pas programmeur et fanatique de LISP mais avec une syntaxe bien plus simple et récusive, tu refais tout XML en propre. »
Bof. Les données semi-structurées, ça fait un bout de temps que ça existe, sauf qu'avant, chacun avait son modèle dans son coin. Ce qu'apporte XML, c'est un compromis entre différents acteurs du monde industriel (Microsoft, Sun, etc.) et scientifiques (universités, INRIA, etc). Comme tous les compromis, il n'est pas parfait, car chacun voulait que « sa » killer-feature se retrouve dans le langage. Mais franchement, on n'en est qu'au début de l'exploitation d'XML. Laissez encore cinq ans aux différents acteurs pour élaborer des méthodes d'interrogation efficaces de XML, et on en reparlera.