Version imprimable
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.
un doc valide:Code:
2
un doc non valide :Code:<livre titre= "xml"> text </livre>
. remarquez le caractère reservé: &Code:<livre titre= "xml & java"> text </livre>
- je ne parle pas ici sur une section CDATA notée: [CDATA[...]]>
merci d'avance
Tout à fait. #PCDATA est le contenu texte d'un élément, utilisable dans <!ELEMENT>.Citation:
Envoyé par win_ubuntu
CDATA est le type "vous faites ce que vous voulez" pour un attribut, utilisable dans <!ATTLIST>.
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é.Citation:
un doc non valide : <livre titre= "xml & java"> text </livre>. remarquez le caractère reservé: &
Qu'essaie-tu de montrer ?
pour moi non (n'oubliez pas les caratères réservés)? sinon on peut dire la mème chose sur le type #PCDATA.Citation:
Envoyé par thelvin
autre chose: valide= bien formé+le doc conforme aux régles définies dans la DTD/Schéma
Ç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 & et <
-- 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.
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.Citation:
autre chose: valide= bien formé+le doc conforme aux régles définies dans la DTD/Schéma
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:et les caractères: &,< appartiennent à "n'importe quoi" ou pas!Citation:
CDATA, le type "n'importe quoi"?
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:
instance:Code:<!ATTLIST livre titre CDATA #REQUIRED>
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 parseurCode:<livre titre= "xml & java"> text </livre>
Oui.Citation:
Envoyé par win_ubuntu
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.
Pas de restriction, donc tout est accepté, c'est à dire, n'importe quoi qu'on mette dedans, c'est accepté.Citation:
- pour quoi vous avez dit:
Citation:
CDATA, le type "n'importe quoi"?
Oui, mais ces caractères-là doivent être échappés, car ils servent au balisage.Citation:
et les caractères: &,< appartiennent à "n'importe quoi" ou pas!
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 & et < est échappé en <
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.
est parfaitement accepté en mettant CDATA comme type de l'attribut test. (Mais il n'y a vraiment que CDATA qui l'accepte.)Code:<condition test="a & b < c" />
Ouais, c'est un choix historique malheureux qui se répercute sur XML.Citation:
Envoyé par win_ubuntu
Le contenu des attributs est parsé lui aussi, pour deux raisons :
- les références d'entité genre < (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é."