XMLCursor, XPath et Namespaces [Résolu]

[Sylvain James]

Bonjour,

Je suis en train de faire un ptit batch d'un document Excel XP au format XML vers une base de données.
Mais le souci c'est que bien que XMLCursor charge correctement le flux XML, toutes mes requêtes XPath ne donnent aucun résultat.

Voici un extrait (heureusement...) de la grappe xml :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?xml version="1.0"?>
<Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:html="http://www.w3.org/TR/REC-html40">
	<DocumentProperties xmlns="urn:schemas-microsoft-com:office:office">
		<Author>SJ</Author>
		<LastAuthor>SJ</LastAuthor>
		<Created>2005-04-08T14:43:45Z</Created>
		<Company>TOTO</Company>
		<Version>10.3501</Version>
	</DocumentProperties>
	<OfficeDocumentSettings xmlns="urn:schemas-microsoft-com:office:office">
		<DownloadComponents/>
		<LocationOfComponents HRef="file:///E:\Officexp\"/>
	</OfficeDocumentSettings>
</Workbook>

Donc si je fais un Cursor.Select('/Workbook') par exemple je devrais obtenir le noeud respectif en résultat mais non je n'obtient rien.
Le seul Select qui me renvoie quelque chose c'est : '/*' :-)

Alors je me demande si il n'y a pas une histoire de namespace là dessous, peut-être faut-il le préciser dans la requête XPath ?

Sylvain

[Pierre FORAZ]

Tu peux faire aussi un select * qui te permettra de naviguer dans la grappe

[RDM]

ah ca les namespaces (surtout ceux par défaut comme celui que tu as dans ta grappe) c'est la grosse M*@#!
ca sert globalemnt a rien sinon a nous embeter lorsque l'on veut fire un trverse dans lagrappe un peu générique.
l'idée la plus simple est de débarasser la grappe XML de son namespace par défaut avant de la charger dans le XMLCursor.

[Sylvain James]

Envoyé par RDM

ah ca les namespaces (surtout ceux par défaut comme celui que tu as dans ta grappe) c'est la grosse M*@#!
ca sert globalemnt a rien sinon a nous embeter lorsque l'on veut fire un trverse dans lagrappe un peu générique.
l'idée la plus simple est de débarasser la grappe XML de son namespace par défaut avant de la charger dans le XMLCursor.

C'est pas l'idéal, ça fait perdre beaucoup de temps car même avec XMLSpy on perd énormément de temps à virer les préfixes dans les attributs (j'ai environ 1500 éléments et 4500 attributs préfixés... dans le doc à traiter).
J'ai remarqué que la méthode XMLCursor.SelectFirst traffiquait avec les namespaces, et pas la méthode Select. Je n'ai pas pris le temps d'investiguer plus loin cependant.

D'autre part je m'en suis sorti en exportant les données en XML à partir d'Access 2003 et non pas Excel 2003.
Oh surprise il y avait bien un namespace de précisé en tête d'XML mais miracle, aucun élément ni attribut préfixé dans le corps des données.
Alors Banco, pour une fois Access m'a rendu service...

Merci à vous,
Sylvain

[RDM]

tu peux aussi le faire avec un méthode en Delphi

[Sylvain James]

Envoyé par RDM

tu peux aussi le faire avec un méthode en Delphi

j'ai essayé mais pareil, impossible de monter le flux dans un XMLCursor, j'aurais pu essayer TXMLDocument pour voir ceci dit...

[mchicoix]

peux etre que tu peux utiliser Delphi en utilisant une librairie gratuite de regular expression pour dire : si tu vois ce type de caractère tu me remplaces par ça ou ça ... j'ai eu l'occasion d'utiliser cette technique pour lire des flux de données en SGML (balise non fermé !!!!)

voilu

[Sylvain James]

Envoyé par mchicoix

peux etre que tu peux utiliser Delphi en utilisant une librairie gratuite de regular expression pour dire : si tu vois ce type de caractère tu me remplaces par ça ou ça ... j'ai eu l'occasion d'utiliser cette technique pour lire des flux de données en SGML (balise non fermé !!!!)

voilu

ah oui d'accord c'est peut-être à ce genre de chose que pensait RDM. En effet c'est une soluce, mais comme mon besoin était ponctuel (je traitais une seule fois ce flux XML et je me servais d'XMLRAD pour aller plus vite et éviter de coder... :-) j'ai opté pour une solution plus rapide : l'export XML d'Access :-)
Merci !