Discussion :

[win_ubuntu]

salut,
quelle est la différence entre #PCDATA et CDATA.
pour moi il n'y a pas de différence sauf un est utilisé pour les éléments et l'autre pour les attributs.

Code :

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

1
2
<!ELEMENT livre (#PCDATA)>
<!ATTLIST livre titre CDATA #REQUIRED>

un doc valide:

Code :

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

<livre titre= "xml"> text </livre>

un doc non valide :

Code :

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

<livre titre= "xml & java"> text </livre>

. remarquez le caractère reservé: &
- je ne parle pas ici sur une section CDATA notée: [CDATA[...]]>

merci d'avance

[thelvin]

quelle est la différence entre #PCDATA et CDATA.
pour moi il n'y a pas de différence sauf un est utilisé pour les éléments et l'autre pour les attributs.

Tout à fait. #PCDATA est le contenu texte d'un élément, utilisable dans <!ELEMENT>.
CDATA est le type "vous faites ce que vous voulez" pour un attribut, utilisable dans <!ATTLIST>.

un doc non valide : <livre titre= "xml & java"> text </livre>. remarquez le caractère reservé: &

En fait, à cause du caractère réservé, ce doc est mal formé. Il ne peut même pas être parsé, donc il n'est pas question de valide ou non valide. Il est mal formé.

Qu'essaie-tu de montrer ?

[win_ubuntu]

CDATA est le type "vous faites ce que vous voulez" pour un attribut,

pour moi non (n'oubliez pas les caratères réservés)? sinon on peut dire la mème chose sur le type #PCDATA.
autre chose: valide= bien formé+le doc conforme aux régles définies dans la DTD/Schéma

[thelvin]

Ça y est, je viens de comprendre.

- D'un côté tu parles de #PCDATA, le type "texte" qu'on peut déclarer comme contenu valide d'un élément dans sa DTD.
Cela sert à la validation.

- D'un autre côté tu parles <![CDATA[ ]]>, la balise d'échappement qui autorise à mettre les caractères spéciaux directement.
Elle n'a rien à voir avec la validation. Quand on a besoin de mettre des caractères spéciaux, on doit
-- soit les échapper du style &amp; et &lt;
-- soit les mettre à l'intérieur d'un <![CDATA[ a && b < c ]]>

Au moment de la validation (et du traitement), que tu aies fait l'un ou l'autre sera ignoré : le balisage sera oublié et il ne restera que le modèle de données.
Bref, <![CDATA[ ]]> n'est qu'une des deux manières, 100% équivalentes et agnostiques de la validation, d'échapper les caractères spéciaux.

Il n'y a donc pas de point commun avec #PCDATA, qui n'est qu'un type de données servant à valider un élément (le type "contenu texte.")

- Je croyais que tu parlais de CDATA, le type "n'importe quoi" qu'on peut déclarer comme contenu valide d'un attribut dans la DTD.
Mais manifestement c'est pas le cas.

autre chose: valide= bien formé+le doc conforme aux régles définies dans la DTD/Schéma

Moi je veux bien que nous décidions de parler comme ça ensemble, mais ce n'est pas la nomenclature d'usage. Et puis de toute façon, si être bien formé est condition sine qua non d'être valide, alors inutile de se demander si un document mal formé est valide.

[win_ubuntu]

en fait, j'aimerai confirmer la chose suivante:
tout texte accepté par le type CDATA (attribut) est accepté aussi par le type #PCDATA (élément), et vice versa.
sinon, un contre exemple

- pour quoi vous avez dit:

CDATA, le type "n'importe quoi"?

et les caractères: &,< appartiennent à "n'importe quoi" ou pas!

sur le Net j'ai trouvé:
Parsed Character Data (PCDATA) is a term used about text data that will be parsed by the XML parser.
-The term CDATA is used about text data that should not be parsed by the XML parser.
moi je ne suis pas d'accord. si on prend l'exempel précédent:

Code :

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

<!ATTLIST livre titre CDATA #REQUIRED>

instance:

Code :

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

<livre titre= "xml & java"> text </livre>

ce fragement contient une érreur. cette érreur doit étre detectée par le parseur(validant ou non validant) n'est ce pas? donc le texte insére pour un attribut de type CDATA est analysé (parsé) par le parseur

[thelvin]

en fait, j'aimerai confirmer la chose suivante:
tout texte accepté par le type CDATA (attribut) est accepté aussi par le type #PCDATA (élément), et vice versa.

Oui.
En DTD, le contenu texte d'un élément est noté #PCDATA et est entièrement libre.
Les attributs, eux, peuvent être restreints à différents types, mais le type CDATA veut dire "pas de restriction."

Donc, l'un comme l'autre peuvent contenir n'importe quoi*, et ce qui est accepté par l'un, l'est par l'autre.

- pour quoi vous avez dit:

CDATA, le type "n'importe quoi"?

Pas de restriction, donc tout est accepté, c'est à dire, n'importe quoi qu'on mette dedans, c'est accepté.

et les caractères: &,< appartiennent à "n'importe quoi" ou pas!

Oui, mais ces caractères-là doivent être échappés, car ils servent au balisage.
Pas seulement dans les attributs : comme contenu d'élément aussi. Toujours. C'est normal, ils servent au balisage. Ne pas les échapper, c'est être mal formé, ce n'est pas une question de validation. La validation ne peut rien faire contre ça.

& est échappé en &amp; et < est échappé en &lt;

Dans le contenu des éléments, on peut les échapper avec une balise <![CDATA[ ]]>, c'est vrai. Il existe donc deux façons de les échapper. Voilà tout.

Code :

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

<condition test="a &amp; b &lt; c" />

est parfaitement accepté en mettant CDATA comme type de l'attribut test. (Mais il n'y a vraiment que CDATA qui l'accepte.)

sur le Net j'ai trouvé:
Parsed Character Data (PCDATA) is a term used about text data that will be parsed by the XML parser.
-The term CDATA is used about text data that should not be parsed by the XML parser.
moi je ne suis pas d'accord. si on prend l'exempel précédent:

Code :

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

<!ATTLIST livre titre CDATA #REQUIRED>

instance:

Code :

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

<livre titre= "xml & java"> text </livre>

ce fragement contient une érreur. cette érreur doit étre detectée par le parseur(validant ou non validant) n'est ce pas? donc le texte insére pour un attribut de type CDATA est analysé (parsé) par le parseur

Ouais, c'est un choix historique malheureux qui se répercute sur XML.
Le contenu des attributs est parsé lui aussi, pour deux raisons :
- les références d'entité genre &lt; (et donc l'interdiction du & non échappé)
- interdire le < non échappé pour éviter les erreurs avec les outils historiques.

Donc puisque le texte des éléments s'appelle PCDATA, le texte des attributs devrait aussi s'appeler PCDATA, c'est logique.
La différence à la rigueur, c'est que du texte d'éléments peut être mixé avec des éléments enfants, ce qui n'est pas le cas du texte d'attributs.
Mais ils s'appellent pas pareil. C'est comme ça. Faisons avec.

De toute façon les DTDs, c'est pas brillant, pour plein de raisons.

* Note : j'ai dit que le contenu texte est entièrement libre et que les attributs CDATA aussi. Ce n'est pas tout-à-fait vrai.
Certains caractères "de contrôle" comme ceux de 0x0 à 0x8 et de 0xe à 0x1f, sont interdits de séjour en XML. Ils ne sont pas autorisés dans le fichier. Cela rendrait le fichier mal formé. Ni échappés, ni "nature," rien. Ni entre les éléments, ni dans les attributs, ni dans les commentaires, nulle part, ils doivent pas être trouvés dans le fichier. Ils rendent le fichier mal formé, ce n'est pas une question de validation, donc quand on dit "tout est accepté," on passe pas son temps à préciser "sauf ce qui rendrait le document mal formé."