Discussion :

[Hibou57]

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

[Hibou57]

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)

[Erwy]

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

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

[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 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 X :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ABCDE <      EFGH
Truc machin

Il ne faut pas faire simplement

Code X :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Mais plutôt

Code X :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Erwy]

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

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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:

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; ) , plus couteux, oui, et sur certains volumes ou/et certaines conditions TROP couteux.

[Hibou57]

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

[Hibou57]

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

Ici Londre, c'est le W3C qui vous parle 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 C'est vrai quoi 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