<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 24 janv. 2020 à 15:36, Thomas Gratier <<a href="mailto:osgeo.mailinglist@gmail.com">osgeo.mailinglist@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Bonjour,</div><div><br></div><div>"Visiblement un développeur de l'ONF a bidouillé "à la main" l'entête XML
 de ce fichier qui n'est visiblement pas créé entièrement par un outil automatique, si on regarde simplement l'indentation changeante et 
inconsistante (qu'un outil automatique n'aurait pas généré comme ça)."</div><div><br></div><div>Complètement faux. L'outil c'est Mapserver et c'est généré automatiquement (cf <a href="https://github.com/mapserver/mapserver/blob/master/mapwms.c#L2992" target="_blank">https://github.com/mapserver/mapserver/blob/master/mapwms.c#L2992</a>)</div></div></blockquote><div><br></div><div>C'est peut-être un serveur mais il se base sur des fichiers macros ou des bouts de code édités manuellement. Et ça se voit dans les warnings laissés en commentaires. Un générateur automatique ne ferait pas ça.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Sinon, j'ai trouvé encore plus simple pour contourner proprement <a href="http://ws.carmencarto.fr/WMS/105/ONF_Forets?request=GetCapabilities&version=1.3.0" target="_blank">http://ws.carmencarto.fr/WMS/105/ONF_Forets?request=GetCapabilities&version=1.3.0</a><br></div><div></div><div>Il faut rajouter la version 1.3.0 dans l'appel GetCapabilities (voir l'url du lien précédent) pour ne plus avoir les mentions Inspire qui font planter JOSM car par défaut c'est la 1.1.1 qui retourne ces références Inspire (suffit de lire le code dans le premier lien fourni pour le comprendre)</div></div></blockquote><div><br></div><div>Ca montre que ça a été un peu bricolé sur un serveur qui n'était pas fait initialement pour ça. Rien que l'inclusion d'une DTD dans un XML montre une solution manuelle de compatibilité (sans doute pour les outils internes maison qui ne savent pas traiter les namespaces XML mais utilisent un parseur XML plus simple, plus ou moins hérité des parseurs SGML; d'où les déclarations SGML, inutiles en XML dont les schémas sont plutôt gérés par des références à des URI d'espaces de noms, et où les préfixes assignés n'ont pas de signification.</div><div><br></div><div>Il suffit de voir que le DTD interne déclare des "attributs" (uniquement pour SGML) alors que ce sont des pseudo-attributs en XML et qu'on n'a pas besoin (ni même normalement le droit) de déclarer, tels que </div><div><!ATTLIST nom-d-élément xmlns:nom-d-espace ...>".</div><div>Un parseur XML ne peut faire qu'ignorer ces déclarations, ou bien les rejeter en mode strict, elles n'ont aucune signification pour lui et ce n'est pas parce qu'on indique que ces attributs sont implicites pour SGML qu'ils signifient quelquechose dans le corps du document, à moins d'un traitement spécial des DTD pour construire le DOM au chargement du document.</div><div>Les namespaces XML sont totalement indépendants des DTD.</div><div><a href="https://docstore.mik.ua/orelly/xml/xmlnut/ch04_04.htm">https://docstore.mik.ua/orelly/xml/xmlnut/ch04_04.htm</a> </div><div> <br></div></div></div>