Ambïguïté de l'interprétation des sections CDATA des documents XML

Bonsoir,

Un détail me tracasse avec les sections CDATA, qui m'inspirent de plus en plus de les écarter autant que possible (pour leur préférer l'échappement standard par les entités de caractères).

Un exemple tout fait m'est venu pendant que je faisais mumuse avec ces fameux fichiers d'archive des MP de Developpez.net

Ces archives encapsulent les corps des messages dans des sections CDATA. Ces messages qui sont à l'origine du BBCode, sont destinés à subir un traitement des espaces identique à celui qui se fait en HTML (à l'exception des balises « code » - j'y viens plus loin, à la fin). Mais d'un autre coté, le CDATA peut (ou est souvent) utilisé pour représenter du code (dans n'importe quel langage), et dans ce dernier cas, les espaces sont à traiter comme des espaces inscécables.

Trés bien, mais si par exemple je traite les espaces des CDATA des archives de MP comme des espaces inscécables, il pourrait y avoir des surprise aprés traitement et affichage : de longues séries de blancs pourraient ne plus être compactées ; comme elles le devraient.

Bref, le CDATA, c'est ambigü, et le mieux est encore d'employer des entités de caractères, qui elles, sont bien plus explicites. Par exemple les archives de Developpez.net pourraient mettre des espaces inscécables dans les balises « code », soit-codé en entités, soit-en caractères Unicode, et les messages seraient encodés eux aussi normalement, en caractères et en entités.

Parce qu'en plus là on voit jusqu'où peut-aller l'ambiguïté : une même section CDATA peut avoir des espaces devant tantôt être traités comme inscécables, tantôt non-inscécables.

C'est ennuyeux ... les sections CDATA.

C'est décidé, je les bannis. D'ailleur j'ai décidé pour mon truc fait maison, que les sections CDATA lues, seraient enregistrées sans CDATA. Mais voilà : comment les lire ??! Par défaut, en considérant tous les espaces comme inscécables, ce qui est loin d'être idéal comme nous l'avons vu précédement, mais qui a au moins l'avantage d'être la moins pire des solutions (traiter tous les espaces comme scecables serait encore pire)

Oilà, c'était le coup de gueule du week-end :)

Note: en plus de convertir les espace en   (  ), il faut également convertir les saut de ligne en 
 : un caractère défini par Unicode pour « nouvelle ligne ».

Il faut donc convertir les CR, LF et CR-LF (en prenant soin de ne pas convertir CR-LF comme CR suivit de LF)

Un XML est un fichier texte , les espaces sont obligatoirement tous "présent".
Les CDATA n'ont rien à voir avec :

Citation:

---

2.7 CDATA Sections
[Definition: CDATA sections may occur anywhere character data may occur; they are used to escape blocks of text containing characters which would otherwise be recognized as markup. CDATA sections begin with the string "<![CDATA[" and end with the string "]]>":]

[..]

Within a CDATA section, only the CDEnd string is recognized as markup, so that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using "&lt;" and "&amp;". CDATA sections cannot nest.

---

Tu confonds le stockage et l'utilisation .
Les CDATA ne sont qu'un outils de stockage
Savoir si les espaces seront insécables ou non dépend de l'outils qui extraiera les données .En XSLT il y a des commandes et options pour ceci , et XSLT ignore les sections CDATA , il ne voit que des noeuds text

Mais dans les sections CDATA, les espaces ne sont pas traité de la même manière. Car dans une section CDATA, on ne fait pas d'interprétation, et donc par exemple " " est différent de " ". Le problème se pose quand on met en CDATA des espace qui aurait dut être compactable. En règle général, les espaces dans les CDATA sont considéré comme non-compactable, mais à cause de cela, on peut considérer comme non-compactables des espaes qui aurait dut l'être.

Ca n'a rien d'une divagation, et la question se pose aussi pour les saut de ligne : dans un noeud texte ordinnaire, les saut de ligne sont des espaces, mais dans une section CDATA, ce sont des saut de ligne. Là encore, quand on met en CDATA des données dans lesquelles un saut de ligne aurait dut être un espace, il y a problème.

Donc bilan : ta théorie selon laquelle les CDATA sont utile pour éviter de faire des erreur en parsant pour remplacer les "&" et "<" par "&amp;" et "&lt;" (ce qui est trés-trés difficile, et hautement risqué, c'est bien connu...) ne tient pas, parce que placer correctement du texte en CDATA, il faut prendre soin de re-traiter les espaces et les saut de ligne. Malhreusement, ceci n'est pas souvent fait.

Par exemple, si je veux mettre ce contenu texte HTML en CDATA

Code:

---

1 2 3

ABCDE < EFGH Truc machin

---

Il ne faut pas faire simplement

Code:

---

1 2 3

<![CDATA[ABCDE < EFGH Truc machin]]>

---

Mais plutôt

Code:

---

1 2	<![CDATA[ABCDE < EFGH Truc machin]]>

---

Donc l'économie de traitement prétenduement atteinte avec les sections CDATA n'est qu'un illusion (trompeuse en plus)

Les CDATA n'apportent absoluement rien qui ne puisse pas être fait avec les entités caractère, mais elles apportent de l'ambiguïté... alors je n'en vois vraiment pas l'utilité. Surtout que ce n'est quand même pas difficile d'échapper automatiquement par logiciel, les caractères "<" et "&", et d'utiliser explicitement "&nbsp;" et autre quand cela est nécéssaire... c'est quand-même plus fiable et plus clair. Et puis si on juge que l'encodage avec des entités caractères consomment trop de place, alors il y a la compression deflat (zip, gzip, et cie), transperente pour beaucoup d'application, et même pour le web et les navigateurs.

Citation:

---

Envoyé par Hibou57

Mais dans les sections CDATA, les espaces ne sont pas traité de la même manière. Car dans une section CDATA, on ne fait pas d'interprétation, et donc par exemple " " est différent de " ". Le problème se pose quand on met en CDATA des espace qui aurait dut être compactable. En règle général, les espaces dans les CDATA sont considéré comme non-compactable, mais à cause de cela, on peut considérer comme on-compactables des espaes qui aurait dut l'être.
[...]
Eh... avant de parler de « diviguations », il faudra peser les mots hein... (à moins que le sens des mots n'ai plus aucune importance)

---

je rappelle
les CDATA en XML c'est

Citation:

---

2.7 CDATA Sections
[Definition: CDATA sections may occur anywhere character data may occur; they are used to escape blocks of text containing characters which would otherwise be recognized as markup. CDATA sections begin with the string "<![CDATA[" and end with the string "]]>":]

CDATA Sections
[18] CDSect ::= CDStart CData CDEnd
[19] CDStart ::= '<![CDATA['
[20] CData ::= (Char* - (Char* ']]>' Char*))
[21] CDEnd ::= ']]>'

Within a CDATA section, only the CDEnd string is recognized as markup, so that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using "&lt;" and "&amp;". CDATA sections cannot nest.

An example of a CDATA section, in which "<greeting>" and "</greeting>" are recognized as character data, not markup:

---

Est qu'on y parle espace, retour à la ligne ??? NON

La gestion des espaces blanc en XML c'est cette partie de la norme

Citation:

---

2.10 White Space Handling
In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, "significant" white space that should be preserved in the delivered version is common, for example in poetry and source code.

An XML processor MUST always pass all characters in a document that are not markup through to the application. A validating XML processor MUST also inform the application which of these characters constitute white space appearing in element content.

A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, MUST be declared if it is used. When declared, it MUST be given as an enumerated type whose values are one or both of "default" and "preserve". For example:

<!ATTLIST poem xml:space (default|preserve) 'preserve'>

<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>The value "default" signals that applications' default white-space processing modes are acceptable for this element; the value "preserve" indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space attribute. This specification does not give meaning to any value of xml:space other than "default" and "preserve". It is an error for other values to be specified; the XML processor MAY report the error or MAY recover by ignoring the attribute specification or by reporting the (erroneous) value to the application. Applications may ignore or reject erroneous values.

The root element of any document is considered to have signaled no intentions as regards application space handling, unless it provides a value for this attribute or the attribute is declared with a default value.

---

C'est l'attribut xml:space qui est en rapport avec la gestion des espace blanc.
Est ce que tu vois CDATA quelque part ? NON

les fins de lignes

Code:

---

1 2 3 4

2.11 End-of-Line Handling XML parsed entities are often stored in computer files which, for editing convenience, are organized into lines. These lines are typically separated by some combination of the characters CARRIAGE RETURN (#xD) and LINE FEED (#xA).   To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character.

---

Est ce que tu vois CDATA quelque part ? NON


Tu confonds l'interprétation , plus ou moins mal paramétré ,de certains outils d'extraction (DOM,SAX,XSLT.....) avec les règles de stockage .


PS:

Citation:

---

Surtout que ce n'est quand même pas difficile d'échapper automatiquement par logiciel, les caractères "<" et "&", et d'utiliser explicitement "&nbsp;" et autre quand cela est nécéssaire... c'est quand-même plus fiable et plus clair.

---

Plus fiable,non,tout ce qui impose un traitement à l'insertion d'une chaine dans un XML rajoute un risque (à te lire ,tu n'as par exemple jamais eu affaire a des outils DOM qui reprotège systématiquement les & à l'insertion; super pratique à la lecture tes &amp;lt; :roll: ) , plus couteux, oui, et sur certains volumes ou/et certaines conditions TROP couteux.

La spécification XML est-elle un référence en matière d'encodage UTF-8 ? Non, et pourtant elle y fait référence.

Il en va de même pour la notion de CDATA qui n'appartient pas à XML mais à SGML. L'usage des sections CDATA est celui dicté par SGML, avec lequel XML se doit d'être compatible, et cet usage défini par SGML est celui qui en fût souvent fait en HTML.

Et il se trouve que : le balisage n'y est pas interprété... pas plus que ne le sont les espaces et les saut de ligne, qui doivent êtres pris pour tel, c'est-à-dire donnée pour donnée, espace pour espace, saut de ligne pour saut de ligne.

Je ne suis quand-même pas né de la dernière pluie sur cette question, et j'ai longtemps utilisé les sections CDATA dans des documents XML traités par XSLT (XSLTProc pour en nommer le processeur). J'en faisais usage pour importer du code dans du XML avec preservation de la mise en forme brute. XSLTProc, comme tout processeur XML qui se respecte, en étant respectueux de la prise en charge spécifique des sections CDATA, a toujours préservé les espaces et les sauts de ligne de ces sections CDATA, en les prennant espaces pour espaces et saut-de-ligne pour saut-de-ligne.

Si certaines applications ne le respectent pas ou l'oubli, je le déplore et en prend la décision de ne plus utiliser de section CDATA, mais ça n'enlève en rien la prise en charge spéciale qui doit être normalement faite des sections CDATA : les prendre pour des données brutes, et non pas pour des noeuds-texte ordinnaires, comme le fait XSLTProc, parmis d'autre (à moins que XSLTProc ne soit pas conforme sur ce point ?).

Logique. cele me fait penser à un point de logique bien connu du monde Prolog : la théorie du monde clos... on ne peut rien déduire d'un contexte qui ne donne ni-réponse affirmative ni réponse négative, et il faut alors s'en référer à un contexte plus vaste. La spécification XML ne dit rien à ne sujet, alors inutile de faire parler du vide, et de lui faire dire ce que l'on veut lui faire dire au pretexte que cela ne dit pas le contraire, par le seul fait que cela ne dit rien à ce sujet.

-- EDIT
Quand il s'agit d'importer du texte provenant de document XML dans des document HTML, il faut convertir le caractère &amp;#8232; (le saut de ligne) en <BR>, car Internet Explorer n'interprète pas corectement le caractère spéciale &amp;#8232;, ni sous sa forme brut, ni sous sa forme encodée en entité-caractère.
-- FIN DE L'EDIT

Citation:

---

Envoyé par Hibou57

L'usage des sections CDATA est celui dicté par SGML, avec lequel XML se doit d'être compatible

---

Inexact
Ce qui est vrai en XML est généralement vrai en SGML (et encore, je parierais pas la-dessus), pas l'inverse.
Je te rappelle que XML est très restreint par rapport à SGML

PS: si quelqu'un connait une adresse web ou serait présent la norme SGML je suis preneur

Le comportement que tu décris n'est pas une généralité liée à xml, cela depend de l'outils d'extraction
Pour XSLT (et donc xsltProc) l'outils d'extraction c'est XPath 1.0, dont voici l'extrait de la norme concerné

Citation:

---

5.7 Text Nodes

Character data is grouped into text nodes. As much character data as possible is grouped into each text node: a text node never has an immediately following or preceding sibling that is a text node. The string-value of a text node is the character data. A text node always has at least one character of data.

Each character within a CDATA section is treated as character data. Thus, <![CDATA[<]]> in the source document will treated the same as &lt;. Both will result in a single < character in a text node in the tree. Thus, a CDATA section is treated as if the <![CDATA[ and ]]> were removed and every occurrence of < and & were replaced by &lt; and &amp; respectively.

NOTE: When a text node that contains a < character is written out as XML, the < character must be escaped by, for example, using &lt;, or including it in a CDATA section.

Characters inside comments, processing instructions and attribute values do not produce text nodes. Line-endings in external entities are normalized to #xA as specified in the XML Recommendation [XML].

A text node does not have an expanded-name.

---

Comme déjà dit tout dépend de l'outils d'extraction et le SGML n'a rien à voir la dedans

La seul chose qu'impose la norme XML c'est l'echappement des caractères, si tu veux crée ton propre langage d'extraction rien ne t'oblige à considérer les CDATA différemment du contenu d'une autre balise.

Attention à propos de la notion abusive de noeud text
Si cette notion existe en DOM et XPath , elle ne recouvre qu' "accidentellement" la même chose , la structure DOM et XPath étant différente sur d'autre point.
La notion de noeud Text n'est donc pas "transverse".
Des rapprochement on semble-t-il été fait entre bcp de normes sans doute pour ne pas toujours "réinventé la roue" mais cela amène aussi malheureusement à de nombreuses confusions

Ce doit être les vacances que je viens de prendre qui m'engourdissent les neurones, mais je ne vois pas quel est le problème avec les CDATA, Hibou57.

Il y a déjà un point, qui n'est pas directement lié aux CDATA mais qui est important à retenir, relevé dans la norme par Erwy : un parseur XML ne DOIT PAS procéder à une normalisation des espaces dits "blancs", mais les transmettre littéralement à l'application cliente, qui décidera quoi en faire. Par exemple, un processeur XSLT, qu'on peut considérer comme un client d'un parseur XML, procède à la suppression des noeuds textes ne comportant que des espaces dans la feuille de style et la source XML, mais ce comportement est défini par la spécification XSLT, pas par la spécification XML.

D'autre part, un bloc CDATA n'est qu'une commodité offerte pour s'affranchir de l'usage des entités et faciliter ainsi la lecture humaine ou la saisie d'un document XML dans un éditeur de texte, ni plus, ni moins. A moindre titre, le fait que le contenu d'un bloc CDATA ne soit pas analysé peut faciliter le travail du parseur et améliorer ses performances, mais ce gain est marginal. On peut absolument tout mettre dans un bloc CDATA, en respectant une contrainte : le texte littéral ne doit pas comprendre la chaîne ]]>. Une application cliente d'un parseur XML n'a aucun moyen de savoir que le texte qui lui est remonté par ce dernier provient d'un bloc CDATA ou d'un texte "normal" dont la source emploie des entités, et en principe elle n'a pas à s'en préoccuper ; une application dépendant de la façon dont est physiquement constitué un document XML (encodage utilisé, usage d'entités ou de blocs CDATA) est très certainement mal conçue...

Finalement je persiste dans l'idée de me débarasser des sections CDATA (l'application peut lire le CDATA, mais n'enregistre jamais avec des CDATA). Et pour interpréter les espaces même en dehors de tout doctype, alors je pense à l'utilisation là où c'est nécéssaire de l'attribut space.

space peut prendre la valeur default ou preserve. Pour ne rien alourdir, il suffit de ne pas écrire l'attribut quand les espaces doivent être compactés (space="default").

Voir l'attribut xml:space

L'attribut pourrait être fixé à l'enregistrement en fonction de l'interprétation du doctype s'il est connu et reconnu, et ignoré à la lecture si le doctype est connu et reconnu, car cette caractéristique peut être inférrée alors du doctype qui me semble prioritaire sur l'attribut (mais est-ce légal de l'ignorer ici ? je veux dire d'ignorer un attribut comme ça.....), ou éventuellement si en lecture un attribut space apparait en contradiction avec le doctype, alors une erreur pourrait être signalée.

Dans le cas de documents sans doctype ou alors dont le doctype n'est pas reconnu, alors il suffirait de préserver à l'enregistrement les attributs space tel qu'ils ont été trouvés en lecture (en ommettant éventuellement d'écrire les attributs space dont la valeur est default)

Je met le tag Résolu ? .... mmmhg, oui, peut-être ;)

Les fichiers produits ne seront pas ceux que l'utilisateur à taper et il faudra par exemple que tu lui explique pourquoi, quand il se servira du DOM, il ne retrouve pas les CDATA qu'il a tapé.
Parce que contrairement à XPath et XSLT , DOM lui a une interface pour le CDATA
http://www.w3.org/TR/REC-DOM-Level-1...l#ID-667469212
et ce n'est pas le seul... en SAX aussi CDATA est un event particulier.
Ton fichier sera du XML mais pas celui créé et voulu par l'utilisateur, ce qui est problème bien plus grave de mon point de vue

CDATA n'est pas un élément sémantique, et donc "<[!CDATA[machin]]>" devrait être identique à "machin". et "<[!CDATA[<]]>" devrait être identique à "&lt;".

Et je pense que quelqu'un qui écrirait des fichiers XML en pensant que les CDATA valent pour eux-même devrait revoir sa conception.

C'est dit un peu brutalement, je m'en excuse, mais les CDATA, vraiment je n'aime pas, et ça ne devrait même pas exister : c'est un sucre syntaxique. Dire que cela fait une différence, serait comme dire que « Inc(a); » est différent de « a := a + 1; » au pretexte qu'un analyseur syntaxique lirait « Inc(a); différement de « a := a + 1; ». C'est peut-être synaxtiquement différent, mais au moment de l'analyse sémantique, le compilateur leur donnera la même représentation interne (qui serait probablement celle de « a := a + 1; »). Je répondrais alors à l'auteur de ce code Pascal, qu'il ne faut pas qu'il s'étonne que « Inc(a); » puisse se retrouver comme « a := a + 1; » dans un code équivalent et strictement de même sens.

Une section CDATA ne peut pas avoir d'attribut, et comme personne ne semble accepter qu'elle puisse avoir implicitement l'attribut « space="preserve" », alors elle « hérite » de l'attribut de l'élément dans lequel elle se trouve, et il suffit donc d'échapper les caractère qu'elle contient quand nécéssaiere, et de traiter les espaces comme l'indique l'attribut explicite ou implicite de l'élément dans lequel elle apparaît. Toutes autres attentes seraient à mon sens non-légitimes.

Note: comme je le disais plus haut, en cas de doctype présent et reconnu, l'attribut space peut être inférré du doctype type, et avoir virtuellement la valeur preserve. Par exemple, une modèle de document définissant un élément pour représenter du code, aurait un élément code, qui preserverait les espaces même si cet élément n'a pas explicitement d'attribut space="preserve". Mais pour faciliter les transmission, alors l'application pourrait ajouter l'attribut space="preserve" automatiquement. De cette manière, une application n'interprétant pas le doctype pourrait tout de même savoir comment traiter les espaces. Et à la lecture, l'application pourrait traiter la source, ignorer l'attribut space="perserve" si elle le trouve (ignoré car implicite de toutes manières), générer un erreur si space à une autre valeur (car en contradiction avec le doctype), et lui donner virtuellement la veleur "preserve" si l'attribut n'est pas présent.

Ceci me semble être la manière la plus claire de procéder.

Citation:

---

Envoyé par Hibou57

CDATA n'est pas un élément sémantique, et donc "<[!CDATA[machin]]>" devrait être identique à "machin". et "<[!CDATA[<]]>" devrait être identique à "&lt;".

---

Tu as des éléments pour ça, parce que tout ce que j'ai lu dit le contraire, notamment comme je l'ai dit pour DOM et SAX pour lesquels c'est un élément syntaxique et ce ne sont pas des amateurs qui les ont écrits.

Pour la comparaison XML/pascal, tu compares les règles d'un langage de programmation avec un méta-langage.

Citation:

---

Envoyé par Erwy

[...] notamment comme je l'ai dit pour DOM et SAX pour lesquels c'est un élément syntaxique et ce ne sont pas des amateurs qui les ont écrits.[...]

---

Un élément s.y.n.t.a.x.i.q.u.e, ce n'est pas un élément s.é.m.a.n.t.i.q.u.e. Le syntaxique, c'est le support, le sémantique, c'est le sens et la valeur des données stoquées.

Do you mind ? ;)

C'est le sémantique qui nous interesse dans un fichier. Deux valeurs sémantiques identiques peuvent tout à fait avoir des syntaxes différentes. Et quand un auteur écrit, disont, une page sur la cuisine avec un format de fichier XML, il/elle écrit pour la sémantique, et non pas pour la syntaxe.

Un document n'a de valeur que sémantique, et n'a aucune valeur syntaxique.

Oilà :D

P.S. About your project, I will write to you as soon as possible, but I'm too much busy at the time beeing.... so later when possible

Citation:

---

Envoyé par Hibou57

C'est le sémantique qui nous interesse dans un fichier. Deux valeurs sémantiques identiques peuvent tout à fait avoir des syntaxes différentes. Et quand un auteur écrit, disont, une page sur la cuisine avec un format de fichier XML, il/elle écrit pour la sémantique, et non pas pour la syntaxe.

---

mais XML est à l'origine(et c'est largement ça fonction la plus répandu) un format de stockage (au moins provisoire), pas de documentation.Tu mélanges avec le HTML.
La façon dont est stocké l'information (syntaxe: attribut,noeud,cdata...) est une donnée.Donnée le plus souvent utilisé par des applications/outils (DOM par exemple) et non des humains.
Le syntaxique est aussi du sémantique à ce niveau, c'est pour cela que c'est un méta-langage .
Et comme déja dit, quelqu'un utilisant une appli basé sur DOM et des XML produit par n'importe quel autre éditeur, prendra le risque de bugger sur le tien.
Le problème n'est pas chez les autres.

Pour ma part, je n'ai toujours pas compris le rapport entre les CDATA et xml:space... :koi:
Les CDATA ne sont qu'une alternative à l'utilisation des entités &lt; et &gt;, ils ne changent rien à la façon dont les espaces seront traités par le parseur.

Citation:

---

Envoyé par GrandFather

Pour ma part, je n'ai toujours pas compris le rapport entre les CDATA et xml:space... :koi:
Les CDATA ne sont qu'une alternative à l'utilisation des entités &lt; et &gt;, ils ne changent rien à la façon dont les espaces seront traités par le parseur.

---

Beh c'est justement là où ce n'est pas clair, parce que c'est souvent interprété comme ça, et c'est même souvent utilisé pour ça. C'est pour ça que je n'aime pas les CDATA.

Tu comprend mieux maintenant ?

Citation:

---

Envoyé par Erwy

La façon dont est stocké l'information (syntaxe: attribut,noeud,cdata...) est une donnée.

---

Non : les CDATA ne sont pas comparables aux noeuds et attributs. Et la différence entre noeud et attribut n'est pas syntaxique, mais sémantique. Et ce sont des considérations sémantiques qui amènent à décider si tel ou tel donnée sera placée dans un noeud ou dans un attribut. Plus précisement, l'attribut commande une partie de la sémantique du contenu du noeud, et pour cette raison, il ne faut surtout pas mettre dans des noeuds des informations de langue, de format, etc. Ce n'est pas une différence syntaxique.

Maintenant, sur ce point, il ne faut pas confondre la logique des attribus en XML et en HTML. Par exemple en XML, si on cré un élément IMAGE, on pourra tout à fait renseigner son URL dans l'élément. En HTML, src est un attribut de IMG, parce en HTML ce qui est dans les noeuds et plutôt destiné à l'affichage... mais bon, je n'ai pas envie de partir dans des question de comparaisons avec HTML.

Et enfin les CDATA, comme le souligne si bien GrandFather, ne sont qu'une manière d'écrire certaines données, en s'épargnant de les échapper. Ce n'est donc pas sémantique mais syntaxique.

En résumé:

• attributs vs éléments = différence sémantique
• CDATA vs contenu avec échappement = différence syntaxique

Citation:

---

Envoyé par Erwy

Le syntaxique est aussi du sémantique à ce niveau, c'est pour cela que c'est un méta-langage .

---

Un métalangage n'est pas un langage dans lequel la sémantique se confond avec la syntaxe.... ça n'a rien à voir (et ce serait d'ailleur un non-sens) : un métalangage est un langage qui décrit un langage. Par exemple si tu parle de la grammaire Arabe en français, le français est un métalangage vis-à-vis de l'Arabe. Si tu utilise un langage qui démontre les caractéristique d'un langage de programmation XYZ, alors ce langage de démonstration est un métalangage. En bref : un métalangage est un langage qui se trouve à un niveau d'abstraction supérieure à celui d'un autre langage, et qui est capable de décrire cet autre langage.

Mais en eux-même, un langage et un métalangage fonctionne de la même manière : ils ont une syntaxe, qui est le support d'un sémantique, mais la syntax n'est jamais la sémantique.

Citation:

---

Envoyé par Erwy

Et comme déja dit, quelqu'un utilisant une appli basé sur DOM et des XML produit par n'importe quel autre éditeur, prendra le risque de bugger sur le tien.
Le problème n'est pas chez les autres.

---

Mais dans ce cas c'est comparable à quelqu'un qui programme en faisant du hacking : ça n'est pas une bonne habitude, et oui, effectivement, il y a des cas où ça ne fonctionne pas. Si j'écris un compilateur par exemple pour un langage XYZ, je ne vais pas m'amuser à reproduire les bugs du compilateur MachinTruc, au pretexte que certaines personnes mal inspirée auraient codé des applications en se basant sur ces bugs. Ils/elles ont fait ce choix, ils/elles doivent être conscient que ça ne fonctionne pas toujours, et ils/elles doivent l'assumer.

Tes exemples sont tous langages de programmations et on parle modélisation de donnée.
Tu parles interprétations alors que le XML ne fait que du stockage, ce sont les autres outils qui l'interprète.
Ca autant de pertinence que d'expliquer le système de fonctionnement d'un sgbdr en prenant comme exemple le modèle objet de java...

Ca me fait penser à tous ceux qui viennent du monde WEB (ou autres spécialité) et qui en découvrant le XML ne voit que cet aspect et le limite à ça, et j'ai lu un paquet de conneries sur le sujet de prof d'université ou autres... :roll:
La aussi ton optique de départ est sérieusement faussé :?
En tout je n'utiliserais pas une appli qui enregistrent des données différemment de la façon dont je les ai entrée sur un format de fichier texte :? Je ne fais pas des fiches de cuisines, je stocke des données pour traitement

Bon moi je laisse tomber mais tu ferais quand même mieux de sérieusement révisé ton approche de départ...

Citation:

---

Envoyé par Erwy

Tu parles interprétations alors que le XML ne fait que du stockage, ce sont les autres outils qui l'interprète.

---

Mais sacré nom d'un scregnegne... si tu fais du stockage sans optique d'interprétation, alors tu ne stoque rien du tout. Le stoquage doit se faire en pensant à l'interprétation à venir, et il doit préserver la capacité d'interprétation. Et même si la transmission de donnée XML (pour rester à un niveau physique) n'a pas à se soucier de l'interprétation, elle a à se soucier tout de même de la préservation de la capacité d'interprétation. Et système qui enregistre du XML, même s'il n'interpréte pas le XML, doit savoir que le CDATA ce n'est rien d'autre qu'une autre représentation, sans échappement, de ce qui aurait put être représenté avec des échappement.

Tu me dis que tu stoque des données : mais ces données n'ont-elles aucun sens pour toi ? Et si ces données n'ont pas de sens, alors comment fais-tu pour les stoquer correctement. Parce qu'à priori, si on considère les choses sans penser à l'interprétation, alors il n'y a même pas de contrôle possible de l'intégrité de ce qui est transmis. S'il existe par exemple un xml:space et
si

Code:

---

1 2 3

<?xml ....> <truc>machin</truc>

---

est exactement équivalent à

Code:

---

1 2 3

<?xml ....> <truc>machin</truc>

---

c'est bien parce qu'on est pas dans une simple représentation physique.

Dis moi donc en quoi "<![CDATA[<]]>" est différent de "&lt;" alors. Parce que sinon on arrivera pas à ce comprendre. Bon, je vais donner l'impression d'insister lourdement, mais ce que j'essais de dire, c'est que si une personne code "<![CDATA[<]]>" en se disant que sa signifie seulement "<![CDATA[<]]>" et que c'est différent de "&lt;", alors cette personne se trompe lourdement.

"<![CDATA[<]]>" et "&lt;" signifie exactement la même chose. Et là ou tu peut avoir l'un, alors il faut t'attendre à pouvoir trouver l'autre également. Et pour allez plus loin, il se trouve que la représentation la plus universel et "&lt;". Et comme de plus l'interprétation des espaces dans les CDATA peut poser problème (à cause de certaines interprétation souvent faites), alors je souligne les problème d'interprétation que peuvent poser les CDATA. Je posais la question seulement pour les espaces... mais alros je ne m'attendais vraiment pas à ce que l'on finisse par me dire que "<![CDATA[<]]>" et "&lt;" ne sont pas interprétable de la même manière.

Et puis non, je ne confond pas langage de programmation et langage de représentation de donnée, mais par contre je sais trés bien qu'à un niveau abstrait les notions de syntaxe et sémantique se retrouve dans les deux. D'ailleurs on peut tout à fait créer si on le souhaite, une représentation XML de n'importer quel langage de programmation, de même que l'on pourrait représenter ce que l'on représente en XML avec une tout autre syntaxe.

Et la raison pour laquelle cela est possible est celle-ci : la syntaxe véhicule une sémantique, il peut y avoir plusieurs syntaxe pour une sémantique, mais ce qui est primordiale, c'est que la syntaxe ne soit pas ambigüe.

........ je ne sais pas.... je pensais que c'était évident pour tout le monde, mais apparement non :roll:

Pour ceux/celles qui auraient encore des doutes . . .

Ici Londre, c'est le W3C qui vous parle :fleche: XML Canonical form (version 1.0 - TR/xml-c14n) (il existe un jeu de teste qui en dérive, avec lequel je valide d'ailleur mon application)

Excusez moi... j'insiste une fois de plus, mais transmettre et stoquer du XML dans l'ignorance de ces règles d'équivalences serait une énorme erreur.

Ce que je retiens de certains propos tenus dans ce fil : il y a des applications qui n'ont de qualificatif XML que le nom, et qui sont trop dépendantes de choses envers lesquelles elles ne devraient absolument pas être dépendantes (à l'exemple des codes de programme qui dépendent de caractérisitiques dont ils ne devraient pas dépendre).

Ah .... au passage, je répond à autre chose : c'est pas parce qu'on vient du monde du Web qu'on n'est pas capable de comprendre XML - et franchement, je ne vois absolument pas ce qui fonde de tels propos (j'ai assez épluché la dernière spécification, et d'ailleur depuis que je les connais, j'ai toujours préféré XML a HTML - même si je préfère HTML à XHTML, mais c'est une autre histoire - ceux/celles qui font du web ne sont pas des personnes plus bêtes que les autres). Zut alors... c'est à préserver les données :mrgreen: C'est vrai quoi :D Qu'est-ce qu'on deviendrait si elles ne voulaient plus rien dire : dans le mot « informatique », ne retrouve t-on pas la même racine que dans le mot « information » ? ;)

Bon, allez.... bonne nuit.... besoin de repos pour tout le monde