« Je dis que la syntaxe des attributs n'est pas un arbre XML donc on perds la recursivité. »
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).
«
> Il faut comprendre justement comment les langages de navigation
> dans les arbres XML et les langages de requêtes sur XML infèrent
> les types.
Il doit manquer des mots ;-)
»
Euh non. :-)
En gros, un langage qui navigue dans un arbre XML, ou bien un langage qui effectue des requêtes dessus (et qui donc en fait, est bien obligé de naviguer dedans ;-) ) se doit d'être un minimum intelligent, sinon il va être assez inefficace :
- s'il considère le doc XML comme un fichier texte, il va juste se baser sur la notion de « bien formé » (une balise ouvrante possède un équivalent fermant) et à la limite, autant utiliser de bonnes vieilles regexps pour chercher l'info qui nous manque (bonjour le mal de crâne).
- sinon, il faut inférer le type de retour concernant la requête de navigation ou d'interrogation de ton doc en règle générale :
si on possède un schéma XML ou une DTD, ça signifie entre autres être capable de prédire (au moins en partie) si une partie du code de la requête examinée ne donnerait pas un résultat qui serait toujours faux (par exemple, demander de trouver une balise qui ne se trouve *jamais* dans une autre), et donc couper certaines branches de la recherche, histoire de gagner du temps. On évalue aussi le type "retour" que la requête devrait renvoyer, lorsqu'il s'agit d'une requête qui effectue des transformations sur un document XML.
Par exemple, on récupère l'ensemble des "//a/b" dans une variable $x et à chaque fois qu'on le trouve, on renvoie "<c>$x</c>". S'il se trouve que <c> ne contient *jamais* les balises contenues dans <b>, alors on peut d'ores et déjà invalider la requête. Le problème survient quand seulement une partie des balises contenues dans <c> se retrouvent dans <b> : là il faut analyser la réponse de la requête (évaluer son type), et comparer avec ce qui est attendu (le type de retour prévu).
«
> genre en XPath, si tu cherches /a//c[@d="untruc"],
Génial !
C'est pile ce que je critique. Le lien entre XPath et XML ?
»
Plus loin, tu te demandes en quoi XPath est spécifique à XML (exemple LISPien à l'appui)
Ma réponse est vraiment toute bête :
XML, dans sa forme « écrite » n'a rien à voir avec ce qu'est XML fondamentalement. Un document XML, c'est un ensemble d'arbres ordonnés et étiquetés. Que sa représentation textuelle soit faite sous forme de balises ouvrantes et fermantes plutôt que sous formes de commandes TeXiennes (\etiquette{...}) ou LISPiennes ( (etiquette '(...)), ou ... on s'en fiche un peu.
NB : en TeX/LaTeX, tu as aussi des attributs, qui ne sont pas récursifs non plus, et qui - surprise ! - sont non ordonnés :
\documentclass[a4paper,12pt]{report}
Dès que tu as des [...], tu as un ensemble de mots-clef (donc non ordonnés, puisqu'il s'agit d'un ensemble).
Concernant le peu de ressemblance entre la syntaxe XPath et XML, c'est vrai. D'ailleurs XML Schema a été créé pour avoir un système de définition de types XML qui soit fait en XML, et pas avec un langage tiers (pas comme les DTD quoi). En pratique, un schéma XML un tant soit peu complexe est très chiant à lire pour un humain, alors qu'une DTD c'est déjà vachement plus simple (le problème c'est que c'est moins puissant, et donc lorsqu'on veut réaliser certaines choses, XML Schema est le seul recours).
Si tu continues comme ça, tu pourrais dire qu'à part XSL/T, les langages de transformation de XML ne ressemblent pas trop à du XML. Par exemple, XQuery utilise une syntaxe FLWR : for / let / where / order by . Et après ? XML est fait pour être lu par des machines. Par contre, les programmes qui manipulent les documents XML (pour rechercher, récupérer, transformer tout ou partie de ceux-ci) doivent être compréhensibles pour l'humain.
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 :-)
[^] # 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.
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).
«
> Il faut comprendre justement comment les langages de navigation
> dans les arbres XML et les langages de requêtes sur XML infèrent
> les types.
Il doit manquer des mots ;-)
»
Euh non. :-)
En gros, un langage qui navigue dans un arbre XML, ou bien un langage qui effectue des requêtes dessus (et qui donc en fait, est bien obligé de naviguer dedans ;-) ) se doit d'être un minimum intelligent, sinon il va être assez inefficace :
- s'il considère le doc XML comme un fichier texte, il va juste se baser sur la notion de « bien formé » (une balise ouvrante possède un équivalent fermant) et à la limite, autant utiliser de bonnes vieilles regexps pour chercher l'info qui nous manque (bonjour le mal de crâne).
- sinon, il faut inférer le type de retour concernant la requête de navigation ou d'interrogation de ton doc en règle générale :
si on possède un schéma XML ou une DTD, ça signifie entre autres être capable de prédire (au moins en partie) si une partie du code de la requête examinée ne donnerait pas un résultat qui serait toujours faux (par exemple, demander de trouver une balise qui ne se trouve *jamais* dans une autre), et donc couper certaines branches de la recherche, histoire de gagner du temps. On évalue aussi le type "retour" que la requête devrait renvoyer, lorsqu'il s'agit d'une requête qui effectue des transformations sur un document XML.
Par exemple, on récupère l'ensemble des "//a/b" dans une variable $x et à chaque fois qu'on le trouve, on renvoie "<c>$x</c>". S'il se trouve que <c> ne contient *jamais* les balises contenues dans <b>, alors on peut d'ores et déjà invalider la requête. Le problème survient quand seulement une partie des balises contenues dans <c> se retrouvent dans <b> : là il faut analyser la réponse de la requête (évaluer son type), et comparer avec ce qui est attendu (le type de retour prévu).
«
> genre en XPath, si tu cherches /a//c[@d="untruc"],
Génial !
C'est pile ce que je critique. Le lien entre XPath et XML ?
»
Plus loin, tu te demandes en quoi XPath est spécifique à XML (exemple LISPien à l'appui)
Ma réponse est vraiment toute bête :
XML, dans sa forme « écrite » n'a rien à voir avec ce qu'est XML fondamentalement. Un document XML, c'est un ensemble d'arbres ordonnés et étiquetés. Que sa représentation textuelle soit faite sous forme de balises ouvrantes et fermantes plutôt que sous formes de commandes TeXiennes (\etiquette{...}) ou LISPiennes ( (etiquette '(...)), ou ... on s'en fiche un peu.
NB : en TeX/LaTeX, tu as aussi des attributs, qui ne sont pas récursifs non plus, et qui - surprise ! - sont non ordonnés :
\documentclass[a4paper,12pt]{report}
Dès que tu as des [...], tu as un ensemble de mots-clef (donc non ordonnés, puisqu'il s'agit d'un ensemble).
Concernant le peu de ressemblance entre la syntaxe XPath et XML, c'est vrai. D'ailleurs XML Schema a été créé pour avoir un système de définition de types XML qui soit fait en XML, et pas avec un langage tiers (pas comme les DTD quoi). En pratique, un schéma XML un tant soit peu complexe est très chiant à lire pour un humain, alors qu'une DTD c'est déjà vachement plus simple (le problème c'est que c'est moins puissant, et donc lorsqu'on veut réaliser certaines choses, XML Schema est le seul recours).
Si tu continues comme ça, tu pourrais dire qu'à part XSL/T, les langages de transformation de XML ne ressemblent pas trop à du XML. Par exemple, XQuery utilise une syntaxe FLWR : for / let / where / order by . Et après ? XML est fait pour être lu par des machines. Par contre, les programmes qui manipulent les documents XML (pour rechercher, récupérer, transformer tout ou partie de ceux-ci) doivent être compréhensibles pour l'humain.
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 :-)