bonjour à tous

lors de l'échange de données au 'format' XML , il peut toujours se poser le problème d'un
document non conforme (not well -formed !!!) .
si le document n'est pas verifier lors de sa création (par exemple depuis une base de données SGBD) ou toutes autres applications
il arrive sur l'application devant le traiter avec des erreurs et ne peut donc etre analyser .

une erreur peut subvenir lors de la saisie de données ( caractères non échappés , de l'iso dans une application unicode ...)
ce qui entrainera également une erreur lors de l'analyse

sur Google , je ne trouve aucun sujet traitant de la vérification de données lors de la réception des données par une application
(mais est-ce possible) , que corriger , et comment la corriger, ...

c'est sur que le traitement doit (devrait) etre fait lors de la saisie et non après la transmission mais existe -il une approche permettant d'assurer ces échanges de façon pérenne .

Existe t-il des techniques ou approche concernant la vérification de ces données xml en amont !?
(j'avais pensé à un traitment xslt pour les caractères sans savoir encore exactement comment aborder ce traitement ..)

merci de vos conseils ...

PS : je vois de plus en plus d'article sur le standard SOAP (je ne connais pas du tout ) ... une "meilleure" solution !?
Salut,

c'est quelquechose de pas evident.je lis:

a écrit :
La notion de XML bien formé est l'exigence minimale pour un document XML. Si un document n'est pas bien formé, sa lecture par un parseur, qui est le programme de lecture de documents XML


donc moralité quand tu exploites ton xml tu dois le parser. donc en fait je ne vois guere de moyen que d'essayer ton parseur et de "try-catch"er les erreurs.

dans l'article que je lis et dont est tirer ma citation ils utilisent SAXPrint ou SAXcount du parseur xerces apparament.

les parseurs SAX etant peu a la mode pourtant tout le monde jurant que par le DOM. ceci dit moi j'aime bien SAX.

maintenant pour un outils de validiter vraiment strict et pas juste je marche/je marche pas
je suis trop peu au fait pour te dire si ça existe.

peut-etre peux tu rajouter une DTD? si le fichier est valide a la DTD j'imagine qu'il doit être relativement bien formé.

quand a SOAP ça fait un moment qu'on en parle 5-6 ans et moi j'aurais plutôt penser que la communication se faisait plus discrete sur ce sujet qu'il y a 3-4 ans mais bon. ça depend un peu de ce qu'on lis comme journaux,site.
Modifié par CPascal (22 Mar 2008 - 12:58)
merci pour tes remarques,

de ce que j'en sais , SAX au contraire d'une analyse 'DOM' , ne parse pas tout le document ...
et 'pointe' plutôt vers une balise ou un endroit choisi ... (les experts me corrigeront surement dans mon
'a-peu-près')

Gros avantage si le doc xml a parser est important (ce qui me fait penser que je ne sais pas s'il est porté sur le PHP ) .. faudra que je gogolise (rien à voir avec google 1ier Smiley murf )

la seule 'solution' qui me plait pas vraiment c'est de retourner à l'envoyeur son fichier si il est mal formé (avec une commnade systeme (rxp ou bien xmllint par ex.) ou un appel php au validator.org et traitement de la reponse (if(oui) else{})

L'article sur developpez.com parle également de la méthode native validate() mais cette vérification demande une DTD et donc une validation sur la sa structure et pas sur sa 'bonne-formation'

par Exemple avec WinDev d'après ce que j'ai lu aucune DTD n'est écrite' ... et comme on (je) suppose qu'on ne sait pas d'où vient le doc XML ... Smiley decu et que celui qui saisi le doc n'a pas les doigts collés Smiley rolleyes

je continue les recherches ...

PS : concernant SOAP (lancé par ... Windows et confirmé par W3C) cela semble une solution assez ...prometeuse (...comme le svg Smiley lol ) ... mais je l'aime moi le svg
Modifié par kzone (23 Mar 2008 - 11:15)
a écrit :
(...comme le svg ) ... mais je l'aime moi le svg


je me disais bien aussi que tu avais comme l'air de t'y interesser Smiley cligne