wazou1812 a écrit:

ce fichier passe très bien en validation W3C

Comment est-ce que tu effectues la validation ? Copier / Scotcher du contenu du fichier -> un formulaire sur w3c.org ?

wazou1812 a écrit:

Mais impossible de le valider avec XMLParseFile quelque soit les options choisies.

J'ai l'erreur :
Error parsing XML document:Invalid document structure Line: 2, Position: 1.

Auriez vous de bons conseils sur ce sujets ?

Merci d'avance,

Tu es sûre du format ?
Si tu ouvres ce fichier avec n'importe quel éditeur sachant manipuler les encodages (emacs, vi, utltraedit, notepad++, scite, ...) et que tu forces la sauvegarde du fichier en utf-8 (en effectuant une modification bidon du fichier, par exemple en ajoutant un espace, pour être sûr que le fichier soit modifié), est-ce que le nouveau fichier est parsable ?

Ici, si je copie ce que tu as posté dans un fichier, et que je place le dtd juste à côté (en supprimant le http://... de l'url pour ne garder que fulfill.dtd) XmlParseFile() fonctionne très bien (résultat = 0)

wazou1812 a écrit:

Bonjour,

Oui, je faisais copier/coller sur W3C, et dans ce cas cela fonctionne, mais si j'importe le fichier, cela ne fonctionne plus, => comportement identique à PB.

Effectivement, le format du fichier n'est pas utf-8, mais utf-16, d’où le problème, si je modifie le format du fichier en utf-8,

Je me doutais que la discordance entre le format réel du fichier et ce qu'il prétend être dans son entête poserait problème. On s'est déjà cassé les dents dessus il y a quelque temps et j'avais fait pas mal de tests sur le sujet.

wazou1812 a écrit:

cela fonctionne avec w3c, par contre avec pb j'ai l'erreur :

Code:

An exception occurred! Type:NetAccessorException, Message:Could not connect to the socket for URL 'http://xml.cxml.org/schemas/cXML/1.2.021/Fulfill.dtd'

J'ai donc 2 nouveaux problèmes :

1°) Comment avoir un fichier xml au format utf-8 avec la fonction savedocument ?

Alors à partir de PBDOM je crois que ce n'est simplement pas possible (depuis que pb est passé à unicode, parce qu'avec pb9, ça fonctionne ). Si tu recherches "pbdom utf8" dans google, tu peux retrouver des discussions sur le sujet dans les newsgroups de sybase où l'on ne m'a jamais infirmé que pbdom fabriquait toujours des fichiers en utf16.

Deux points :
- d'après notre expérience ici, cela ne pose aucun problème à partir du moment où l'entête de ton fichier indique bien "utf-16le" pour l'encoding. L'utf-16 est parfaitement supporté par xml et tu ne devrais pas avoir de problème à manipuler de tels fichiers.
- si vraiment, vraiment, vraiment tu veux avoir un fichier en utf-8 ici la seule solution qu'on a trouvé consiste à tricher en enregistrant fichier utf-8 "à la main" :

    int ll_hfile
  ll_hfile = FileOpen( "c:\temp\pbdomtest8.xml", StreamMode!, Write!, LockReadWrite!, Replace!, EncodingUTF8! )
  if ll_hfile > 0 then
    FileWriteEx( ll_hfile, Blob( PBDOM_DOCUMENT_SHIP.savedocumentintostring( ), EncodingUTF8!) )
    FileClose( ll_hfile )
  end if

wazou1812 a écrit:

2°) Pourquoi, il n'arrive pas à se connecter  pour contrôler le dtd sur l'adresse http ?

Là, je ne sais pas. Ici le proxy web m'empêche d'aller sur cxml.org, c'est pour ça que j'ai récupéré le dtd par un moyen détourné, et que j'ai elenvé le début de l'url pour que la validation trouve le dtd dans le même répertoire que le fichier xml.
Peut-être as-tu le même problème ? Est-ce que tu arrives à accéder directement à http://xml.cxml.org/schemas/cXML/1.2.021/Fulfill.dtd ?

wazou1812 a écrit:

Bonjour,

Pour l'encodage utf-8 ou utf-16, le problème est que le fournisseur nos demande de produire un fichier en utf-8, et la question est donc de savoir s'il pourra ou pas 'exploiter' nos fichiers si nous spécifions utf-16 ? La logique voudrait que oui, mais ?

Si c'est demandé comme cela... Après tout le FileWriteEx() à la place du SaveDocument(), ce n'est pas un bidouillage trop dégueu. Et tout le contenu du fichier a été généré par PBDOM.

wazou1812 a écrit:

Pour l'accès à la page du dtd, j'ai comme message sur firefox

Code:

Et sur IE, ça donne

Code:

Ici avec Chrome j'ai

This page contains the following errors:

error on line 15 at column 2: StartTag: invalid element name
Below is a rendering of the page up to the first error.

ce qui revient à peu près au même.

wazou1812 a écrit:

ça veut dire que je n'ai pas accès au DTD en ligne ?

Ce qui est dommage si je ne peux pas accéder au dtd en ligne, c'est que je ne pourrais jamais utiliser systématiquement la fonction xmlparsefile sur les fichiers que je constitue.
Ou alors il faudrait que je constitue 2 fichiers en parallèle, l'un destiné à être envoyé, et l'autre à être contrôlé, c'est pas cool.
D'un autre coté, est-on obligé de contrôler les fichiers que l'on constitue ?

Merci seki pour ton aide très précieuse,

Là je ne sais pas trop. Tu passes par un proxy web ? Éventuellement, tu pourrais vérifier qu'il ne faille pas compléter quelque chose dans le menu Tools / System Options / Onglet « Firewall settings »
Si il arrive à afficher un problème de syntaxe c'est qu'il arrive à récupérer le fichier dtd. Maintenant il faut peut-être des fichiers complémentaires ?

On n'utilise pas la validation par dtd ici, par contre on fait de la validation par schéma xsd, ce qui est un peu équivalent. Je vais voir si je peux trouver des infos là dessus.

Je ne pense pas que tu soies obligée de valider mais l'expérience montre que c'est bien de le faire lorsque les infos proviennent d'une saisie d'un utilisateur. Parfois l'utilisateur peut saisir des données invalides (ou en omettre) et le fichier résultat n'est plus conforme au schéma. Si tu peux repérer des problèmes en amont avant envoi, c'est mieux que de passer pour un incompétent quand c'est le client / fournisseur qui te signale que tes fichiers sont invalides

Je ne crois pas que le problème soit au niveau du réseau/proxy. Après en avoir discuté avec xlat, il m'a rappelé que PBDOM ne savait pas valider de document xml à partir d'un schéma (ou d'un dtd) en ligne. C'est pour cela qu'ici lorsqu'on valide nos fichiers xml, on donne un chemin local vers notre xsd. Quand on transmet vraiment le fichier on met l'url « officielle ».

D'ailleurs un rapide test en supprimant l'attribut timestamp du noeud cXML et en ne conservant que "Fulfill.dtd" dans le doctype ( à la place de   "http://xml.cxml.org/schemas/cXML/1.2.021/Fulfill.dtd") me donne le résultat suivant lors du XmlParseFile() :

---------------------------
XML Parsing Error
---------------------------
Error parsing XML document:

Required attribute 'timestamp' was not provided

c:\temp\pbdomtest8.xml, Line: 3, Position: 46.
---------------------------
OK   
---------------------------

Donc la validation s'effectue bien en local.

En gros ce qu'on te suggère c'est de procéder en 2 temps :
1) tu fabriques ton document cxml en précisant un path local pour le DTD lors de l'appel à NewDocument()
1 bis) tu valides le document directement en mémoire avec un XmlParseString(PBDOM_DOCUMENT_SHIP.SaveDocumentIntoString( ))
2) tu recommences un autre NewDocument() avec la vraie url du DTD et tu sauves ton fichier en utf-8 avec le truc du FileWriteEx(SaveDocumentIntoString( ))

Qu'en penses-tu ?

(Message édité pour enlever quelques typos, trop tard car il a déjà été cité )

Dernière modification par seki (30-09-2011 14:42:52)

seki a écrit:

Après en avoir discuté avec xlat, il m'a rappelé que PBDOM ne savait pas valider de document xml à partir d'un schéma (ou d'un dtd) en ligne.

On vient de faire un petit test en replaçant http://xml.cxml.org/schemas/cXML/1.2.021/Fulfill.dtd par http://pc-geni/Fulfill.dtd (pc-geni est une machine locale où tourne un serveur web de test). La validation s'effectue aussi sans problème sur un serveur http distant.

Par contre ici le problème semble bien lié à notre proxy. Il est assez capricieux et nécessite une "authentification NT" que PBDOM ne semble pas capable de lui fournir (je n'ai pas regardé avec un analyseur réseau en détail pour confirmer le problème). J'ai d'autres applications (svn, certaines mises à jour éclipse ou jedit ) qui échouent à cause du même proxy, alors que depuis d'autres sites ça fonctionne.

PBDOM n'est pas tant incapable que cela

Par contre pour le truc de la validation en mémoire, il faut espérer que les documents cxml ne seront pas trop gros, (PB)DOM c'est gourmand en mémoire.

Dernière modification par seki (30-09-2011 14:41:56)