Parse un XML contenant une DTD n'existant pas

Version imprimable

Bonjour

Pour un projet sur lequel je travail, je doit pouvoir effectuer les opérations suivantes :
- Charger un modèle de fichier XML (c'est un fichier XML)
- Effectuer quelques modifications
- Pouvoir l'enregistrer à un endroit donné.

Le problème que je rencontre vient du fait que mon application (sous Windows) manipule un fichier qui doit être utilisé sous LINUX, et dont la DTD doit être en chemin absolu. Cette DTD doit être absolument être présente dans le fichier générer, conformément à ce qui est présent dans le modèle XML. Je ne peux pas préjuger du contenu de ce modèle.

Si j'effectue les opérations suivantes :
Code:

1 2 3 4 DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setValidating(false); DocumentBuilder builder = factory.newDocumentBuilder(); Document doc = builder.parse(file);
le parser se plaint comme quoi il ne trouve pas la DTD (setValidating(false) n'a pas l'air de faire ce que je souhaite).

Je peux obtenir un parsing correct en ajoutant ceci :
Code:

1 2 3 4 5 6 7 8 builder.setEntityResolver(new EntityResolver() { @Override public InputSource resolveEntity(String publicId, String systemId) throws SAXException, IOException { return new InputSource(new java.io.StringReader("")); } });
avant le parse. Oui mais... je perd la DTD lors de la sauvegarde de mon document.

Voyez vous une solution ?

28/07/2011, 14h56
tchize_

1) a quoi ressemble le doc de départ
2) à quoi ressemble le doc d'arrivée que t'obtiens
3) que devrais-tu obtenir
4) quel est ton code de chargement / modification / sauvegarde (on n'a que le chargement là)
28/07/2011, 17h23
thelvin

Citation:

Envoyé par jfouche

le parser se plaint comme quoi il ne trouve pas la DTD (setValidating(false) n'a pas l'air de faire ce que je souhaite).

Ça fait, littéralement, ce que ça dit que ça fait. Ça dit qu'il ne faut pas valider.
Si tu dis à ton enfant de ne pas aller mettre le désordre au salon. Tu ne lui as rien dit sur le fait d'aller au salon : il y va, il y va pas, c'est son problème. En tout cas, qu'il y aille ou pas, il a ordre formel de ne pas le mettre en désordre.
C'est pareil avec le parseur XML. Tu lui as dit de ne pas valider, à tes ordres, il ne validera pas. Quoi ? Ne pas aller lire la DTD ? Personne ne m'a parlé de ça.

Explication : validation ou pas, la DTD pourrait contenir des définitions d'entités internes (ou externes, d'ailleurs). Il ne sait pas s'il y en a, mais s'il y en a il les lui faut. Donc il va les chercher. Ça n'a rien à voir avec la validation, qui est rappelons-le, la vérification que le document respecte une grammaire annoncée.
Il me semble qu'on peut lui dire de ne pas chercher à aller voir la DTD, mais je ne sais plus comment. Ça a à voir avec http://apache.org/xml/features/nonvalidating/load-external-dtd, trouvable ici : http://xerces.apache.org/xerces-j/features.html

Citation:

Envoyé par jfouche

Oui mais... je perd la DTD lors de la sauvegarde de mon document.

Rien à voir avec EntityResolver. Il ne touche pas au DOCTYPE annoncé par le fichier. Le problème est ailleurs.
Notamment, la bonne vieille technique de sérialiser le Document avec un Transformer, efface toujours le doctype. L'une des nombreuses raisons pour lesquelles j'utilise plutôt JDOM.
28/07/2011, 18h15
tchize_

Je rajoute qu'une DTD c'est une forme basique d'inclusion de définitions dans un document xml. Le transformer peux très bien prendre le contenu de la DTD et l'inclure telle quelle dans le document final plutot que de mettre un lien vers un document DTD.
28/07/2011, 19h09
jfouche

Thelvin, merci beaucoup pour les explications, c'est plus clair pour moi.

Citation:

Le problème est ailleurs.
Notamment, la bonne vieille technique de sérialiser le Document avec un Transformer, efface toujours le doctype.

Bah voila, c'est ce que je fais...

Citation:

L'une des nombreuses raisons pour lesquelles j'utilise plutôt JDOM.

Par contre, j'essaie de limiter au max le nombre de COTS pour mon produit, et j'aurai préféré une solution qui n'utilise pas une bibliotheque externe. J'ai rajouté le doctype récupérée avec l'EntityResolver au transformer, mais ça ne me parait pas terrible comme solution. En plus, ça rajoute file: au chemin de la DTD, ce que je n'ai pas testé avec le soft linux.

PS : Le lien fourni ne marche pas...
28/07/2011, 23h01
tchize_

si vous voulez convertir le url en nom de fichier , faites un

Code:

new File(new URL(ligne).toURI())

Je fais ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Source source = new DOMSource(this.doc);
File file = new File(filename);
Result result = new StreamResult(file);
try
{
	Transformer xformer = TransformerFactory.newInstance().newTransformer();
	if (this.systemDTD != null)
	{
		xformer.setOutputProperty(OutputKeys.DOCTYPE_SYSTEM, this.systemDTD);
	}
	xformer.transform(source, result);
}
catch (Exception e)
{
	e.printStackTrace();
	return false;
}

Difficile de proposer une conversion...

29/07/2011, 09h57
thelvin

Utilise plutôt doc.getDocType().getSystemId(), inutile de chercher midi à quatorze heures.
Attention quand même, getDoctype() renvoie null pour les documents qui n'ont pas de doctype.

Citation:

Par contre, j'essaie de limiter au max le nombre de COTS pour mon produit, et j'aurai préféré une solution qui n'utilise pas une bibliotheque externe.

En Java ??! Non, non, je ne juge pas, chacun ses petits masochismes...

Citation:

PS : Le lien fourni ne marche pas...

Quoi, http://xerces.apache.org/xerces-j/features.html ?
Il marche maintenant, le serveur devait être down.
29/07/2011, 10h06
jfouche

Citation:

Citation:

Par contre, j'essaie de limiter au max le nombre de COTS pour mon produit, et j'aurai préféré une solution qui n'utilise pas une bibliotheque externe.

En Java ??! Non, non, je ne juge pas, chacun ses petits masochismes...

C'est plutôt qu'on a du envoyer au client la liste des COTS utilisé sur notre produit. Changer cette liste maintenant a un coût. De plus, nous passons un peu de temps à faire une analyse juridique des COTS que nous utilisons, et ça aussi a un coût (financier et temps).
D'où ma recherche d'une solution sans COTS aujourd'hui. Par contre, nous utilisons bien plusieurs COTS sur notre produit (je ne refais pas qqchose qui existe...). Certains open sources, et d'autres achetés (ex : JIDE, que je conseil pour le rapport qualité / suivi / coût).

Citation:

Envoyé par thelvin

Utilise plutôt doc.getDocType().getSystemId(), inutile de chercher midi à quatorze heures.

Ca cartonne, en mieux que ce que j'avais : cela ne préfixe pas par file:
29/07/2011, 11h12
tchize_

Il doit être magique votre chef de projet, si il sait avant le développement de quelles librairies vous allez avoir besoin :mrgreen: