Bonjour,
 
 au lieu d'utiliser des fichiers plats, j'aimerai utiliser un format de type XML, mais formalisé.
 
Voici mon fichier :

 
Le but de ce fichier est de permettre à une application de générer via PHP un menu JavaScript dynamiquement.
Ainsi, MainMEnu correspond a une section principale, Element a un element rattaché a la section principale....
 
L'attribut comments me permet, si je veux ulterieurement utiliser un frontend pour configurer ce fichier, de savoir a quoi correspondent les section.
 
Pourvez vous me dire si ce formalisme est correct ?

Pour savoir s'il est standard, ecris-toi u n fichier DTD.
Tu ajoutes un DOCTYPE à ton fichier XML pointant sur ton DTD, et tu peux faire valider le fichier par le validateur HTML fu W3C.
 
Par exemple :
 
http://validator.w3.org/check?uri= [...] 2Fdisk.xml
 
Le fichier XML :
 
http://stats.manga-torii.com/disk.xml
 
Le DTD :
 
http://stats.manga-torii.com/disk.dtd

Moui, enfin la DTD est pas obligatoire s'il ne veut faire que du XML bien formé.
Il peut facilement fabriquer un validateur de XML bien formé en utilisant expat.
A+,

les noms d'éléments et attributs ne doivent-ils pas etre en minuscules?  
en tous cas c'est laid

J'en sais rien c'est pour cela que je demande.
Et si t'es la pour apporter des avis aussi puerils tu peux retourner a la garderie et faire ton mariole

ben je n'en suis pas sur, c'est donc à vérifier.  

Non, le XML est case sensitive, mais ça s'arrête là.
 
La preuve :
 
http://validator.w3.org/check?uri= [...] 2Fdisk.xml
 
Et le code XML :
 

 
Merci pour ces explications.
Toi qui est a fond dans cette "norme" apparement, on se sert de XML/XSL pour generer/afficher du contenu.
Par contre pour tout ce qui est utilisation de XML pour fichiers de configuration dans une application, doit on aussi respecter rigoureusement les conventions ?
Par exemple y a t-il des regles a respecter pour faire soon propre parser ? Je sais que OpenOffice et Compiere utilsent XML en grande quantité par contre ce ne sont pas des applis Web et leur utilisation de XML est totalement differente

Les seules règles à respecter sont :
 
1) Les tags et attributs sont case sensitive. Si tu as un tag <folder> il ne sera pas assimilé à <FOLDER> par exemple. Ce sont deux tags différents.
2) Tout fichier XML doit normalement faire l'objet d'une déclaration DTD, qui défini l'arbresence et les types de données qu'il y a dans chaque tag/attribut. Tu peux t'en passer, ce n'est pas obligatore, mais à ce moment, on ne peux pas savoir ce que tu attends comme informations.
3) Tout tag est délimité par < et >, même si c'est noyé au milieu du flux XML. Tout tag doit être fermé avec </tag> ou <tag/>
 
Sinon, y'a pas grand chose de particulier à propos du XML, c'est une techno relativement simple. Par contre, je vois pas trop l'intérêt de faire son propre parseur, il faut mieu en prendre un existant, qui aura l'avantage d'avoir plus de chances d'être conforme à la norme (parce que la norme ne s'arrête pas à ce que j'ai dit, j'ai dit que le principal )

Ah, si, un truc TRES important : l'enctype d'un fichier XML, tout comme celui d'un fichier XSL doit être us-ascii. Il est possible d'utiliser un autre encodage, mais c'est très fortement déconseillé par la norme, d'ailleurs le validateur W3C ne manque pas de te le rappeler si tu ne respectes pas cette recommandation.
En effet, le XML est à la base écrit pour être le plus portable possible, et être capable de passer à travers n'importe quel firewall en mode texte. Si tu fait du UTF-8 par exemple, ton flux va passer en mode binaire, ce qui peut résulté en unecorruption lors d'un rappatriement par FTP ou quand tu passes à travers un firewall. Deplus, tous les PC et ordinateurs en général supportent l'ASCII, mais ce n'est pas le cas des autres encodage.

Oki merci pour les infos.
Je pensais pas que c'etait aussi contraignant le XML. En tout cas, je vais m'efforcer à respecter ces regles.
Connaitrais tu un Parser XML libre de droit et pas trop compliqué à implementer, ecrit en PHP de preference (ou Perl), que l'on peut intégrer sans aucun probleme à une application non commerciale ?

http://fr.php.net/xml

Si c'est pour nux, bah t'as logiquement le package pour apache qui fait ça très bien.
Sinon, si c'est par exemple pour une appli windows, pas besoin de chercher midi à 14h, le parseur MSXML fonctionne très bien. Sa seule limitation, c'est qu'il ne tiens pas compte de la DTD pour valider le XML (il vérifie juste que syntaxiquement il est correct)

 
Non, pour une fois, je ne suis absolument pas d'accord. L'encodage par defaut est UTF-8 et c'est celui la qu'il est recommandé d'utiliser (ou tout autre systeme supportant unicode de maniere native, sans passer par un jeu d'entites):

XML a des le depart choisi cette solution, car l'utilisation de US-ASCII avait révélé pas mal de pbs en SGML, et meme avec l'emploi d'entites caracteres.
US-ASCII est un sous ensemble de UTF-8, mais il est trop limitatif. Comment fais tu alors si tu as un caractere japonais ou meme pour le francais, le caractere o dans l'e, ?, dans ton texte? On peut evidemment passer par les entites caracteres, mais ca n'est pas la panacée.
 
S'il y a des pbs au cours de la chaine de transmission, c'est parce que celle ci aura ete mal configurée. S'imposer d'encoder en US-ASCII, c'est contourner le probleme, et non le resoudre.
 
A+,

Pour les noms d'element et d'attributs, ils peuvent en effet etre en majuscule ou minuscule ou tout mélange. xml est case-sensitive.  
Mais il y a des contraintes a respecter sur la premiere lettre de ces identificateurs (une lettre, un chiffre ou _ ou : ) et les lettres suivantes.
A+,

Bah écrit un fichier XML sans spéécifier l'encoding, avec une DTD.
Envoie-ça au parseur XML du site www.w3.org, et il réponds qu'il n'a pas pu détecter le charset, et qu'il a décidé de faire la validation en utilisant us-ascii, ce qui est fortement recommandé par la norme. C'est écrit en toutes lettres.
Alors après, si dans la norme elle-même ils écrivent le contraire, faudra qu'ils pensent à se mettre d'accord
 
Sinon, j'en reviens au UTF-8
Comme son nom l'indique, c'est un encodage sur 8 bits.
Hors aujourd'hui encore, beaucoup de firewall sont configurés pour ne laisser que des flux texte, c'est à dire 7 bits quand l'enctype est text/xxx, ce qui permet à coup sûr de filtrer tout programme indésirable, ou contenu style divx maquillé.
A ce moment, soit ton fichier va carrément pas passer, soit il va être altéré.
 
Dans tout les cas, il faut garder en mémoire que le XML, c'est pas fait pour faire des jolis sites web, ni des fichiers de configuration. A la base, ça a été écrit pour :
- Fournir un format de fichier évolutif afin de stocker des données
- Et permettre d'échanger ces données entre sites (je parle de sites au sens informatique, pas des sites web) de façon plus légère que ODBC par exemple.
 
Hors, ODBC pouvait très bien être paramètré pour passer sur le port 80 ou 21, son seul désavantage par rapport au XML réside dans le fait que c'est un flux binaire, et accessoirement, qu'il nécessite que les deux serveurs communiquants soit allumés en même temps.
En effet, le XML n'a pour avantage que le fait d'être transportable (donc passer à un encodage 8 bits c'est condamner un de ses principaux avantages) et de fonctionner en mode déconnecter (on peu uploader des fichiers XML sur un ftp, puis les récupérer deux jours après).
 
Tout ça pour dire que je trouve parfaitement illogique qu'il soit recommandé d'utiliser UTF-8

C'est un joli raisonement ça : On part du postulat qu'il y a des firewall mal configurés sur Internet pour arriver à la conclusion qu'il ne faut pas utiliser l'UTF-8 comme encodage pour les fichiers XML. Chapeau !

C'est parcequ'on est parti de ce postula que le XML a vu le jour. Parcequ'une connection ODBC est autrement plus performante et simple à mettre en oeuvre qu'un fichier XML.
 
Faudrait voir à rester logique un peu...

 
Primo, non, UTF-8 n'est pas un encoding sur 8 bits, mais un encoding de taille variable, sur 8, 16, 24 ou 32 bits, et secondo, comme je l'ai dit, si tu as un pb au passage d'un firewall, c'est parce que ta chaine de transport est mal configurée: Soit tu surencode ton XML au depart, avec , et tu le decodes a l'arrivée, c'est typiquement ce que va faire un protocole ftp si tu imdique un mode binaire (et donc, configurer ta chaine de transport dans ce cas precis signifie la configurer afin que ce soit ce parametrage qui soit utilise), soit tu utilises un encodage compatible avec ton transport (UTF-7 [RFC 2152] par exemple, si tu passes par des routages qui ne supportent que le 7 bit).
 

Ca te semble illogique, et pourtant, la raison en est claire (d'un point de vue compatibilité): Pour un document dont le jeu de caracteres est ASCII, ces deux encodages sont identiques; UTF-8 est une extension au jeu de caracteres unicode de l'encodage ASCII.
 
D'autre part, c'est bien sympa ce que tu dis precedemment, mais ca ne dit en rien ce que tu fais lorsque tu as tes données XML en japonais. Ou en chinois, ou autre...
Ou meme en francais, car je te rapellle que le scaracteres accentués sont en dehors de l'ASCII.
Passer par des entites caracteres a beaucoup d'inconvenients, le principal etant qu'il oblige d'avoir une DTD. Or XML ne necessite pas necessairement l'emploi d'une DTD, et si je veux faire du XML well-formed en japonais, je ne peux employer d'entites.
 
Ca te semble peut etre bizarre ce besoin de faire du XML well-formed, sans passer par une DTD, mais c'etait un des besoins essentiels des clients de mon ancien produit:
- Recuperer du texte taggé sans DTD
- Mapper automatiquement certains objets de formatage (essentiellement les tables)
- L'editer
- Le mettre en forme (+/- CSS en plus complexe crée a la volée pour le premier document, et appliquée a une classe)
- L'imprimer et/ou le sauver en PDF.
 
A+,
 

 
Non, XML a vu le jour a cause des nombreux defauts de SGML (dont je suis un specialiste).
 
Grosso modo, SGML ne supportait pas de maniere native les references externes (chaque editeur avait sa solution ad-hoc), les jeu de caracteres complexes (il y avait des solutions, mais lourdes), et les feuilles de style.
D'autre part, SGML avait tout un tas de possibilites tres lourdes et tres peu employées (DATATAG, ...) qui rendaient l'ecriture d'un parseur une tache tres tres complexe.
 
XML a pallié aux lourdeurs du parsing SGML en virant enormement de choses (ils ont d'ailleurs trop simplifié, en virant la construction & qui etait tres tres utile), en adoptant un jeu de caractere (unicode) qui supporte l'essentiel des caracteres utilises, et en adoptant les mecanismes de HTML pour les references externes.
 
Au depart, XML a ete concu par des gens specialises dans le documentaire, et c'est dans les 6 mois/un an, apres la premiere conf intitulée SGML/XML conference que l'orientation transport de donnée informatique pure (ie ne correspondant pas a un document stocké, mais a une communication de données entre systemes informatiques) a commencé a se develloper.
 
A+,

 

très, très bon

 
Mais tu dis tes bêtises partout dis donc
L'UTF8 peut-être transmis et traité comme un texte en ASCII étendu (8 bits)
 

 
ça dépend comment tu le vois. Pour un soft qui ne connaît que l'ANSI (enfin, le truc classique sous Windows là, avec 8 bits par acractères), il ne va pas abîmer l'UTF8, il va juste afficher les caractères étendus sur 2, 3 ou 4 caractères). Alors que de l'UTF16 contient par exemple des 0 devant les caractères stockés dans 1 octet (lettres simples, etc.), et ne peut donc pas être lu "bêtement"

Juste au passage, tu es axtrêment rarement maître de l'environnement dans lequel tu fais tourner ton appli.
 
Pour cette raison, je ne trouve même pas illogique, mais dangereux de reposer sur des suppositions pour faire ce genre de choix. Tu ne peux en aucun cas être sur que tout le long du transport, les différents admin réseau on bien fait leur boulot. Tu ne peux pas non plus t'assurer que les serveurs qui vont utiliser ton appli supportent différents charset, ni les appli qui vont communiquer avec.
 
Je pense simplement à un cas réel :
 
Interfaçage entre Oracle Application / GHX / Generix
C'est une interface sur laquelle j'ai bossé qui permet d'échanger des informations de commandes entre deux ERP utilisés par différents pôles au sein d'ue même groupe.
 
Oracle Application est capagle de gérer du XML et de l'UTF-8 y'a pas de problème.
Seulement, Generix ne supporte ni l'un ni l'autre.
Il faut donc passer par GHX, qui va se charger de changer le XML en format EDI, un autre standard d'échange de fichiers. Ce dernier une sorte de format CSV d'un format défini de façon standard, assez merdique, et on ne peut en aucun cas supporter de l'UTF-8, car la taille d'un caractère doit être fixe. Deplus, au final, pas plus Generix que la version d'Oracle sur laquelle il se repose ne supportent cet encodage, donc ça ferait très sexy d'avoir des caractères incompréhensibles plein le catalogue. Un énorme problème a été évité par un coup de chance incroyable : l'extracteur XML d'oracle application, qui était mal configuré, remplaçait tout les caractères étendus par le plus proche en ASCII simple. Du coup on n'a jamais eu le problème. Si Oracle Application est paramtré par défaut de cette façon, je cherche pas plus loin, c'est qu'il y a une raison... Et mon expérience en est la preuve.
Quand tu bosses sur un système, surtout quand on parle de protocole d'échange (le XML faisant partie d'un protocole d'échange, en tant que support), on bosse rarement avec des outils dont on est maître, ou qui soit récents... Faut faire avec ce qu'on a sous la main, et prendre l'habitude dans un premier temps, de savoir trouver le plus grand dénominateur commun, et dans un second temps l'appliquer est un peu plus précieux que ce dire "putain cette techno c'est trop fort, en plus c'est standard et tout". Bah ouais, parceque la vie c'est pas le site du W3C, tout n'est pas parfait, et on bosse tout les jours avec des choses qui ne sont pas aux normes, tout simplement parceque les normes ça évolue, et que les outils n'évoluent pas toujours avec.

Antp, Oui, c'est pour ca entre autres que UTF-8 est recommandé: en general, du code qui marche correctement avec les chaines de caracteres "C" (caractere sur 8 bits et 0 pour indiquer une fin de chaine) marchera correctement avec une chaine de caractere UTF-8, tant que ce code n'essaie pas de modifier la chaine.
A+,

 
je ne vois pas le rapport, moi je traite bien des fichiers XML UTF8 avec un parseur qui ne supporte que l'ISO8859 et qui traite ses chaînes avec des caractères 8 bits.
 
edit: cf remarque de Gilou juste au-dessus

Il fut un temps (des années) ou ca marchait, et je dois dire que je preoccupe peux des infos du profil.
A+,

MagicBuzz, je ne disconviens pas que dans certain cas precis, les outils ne soient pas adaptes et ne permettent pas d'exploiter XML, mais seulement une partie de XML.
 
Je suppose que dans ton projet Oracle... On n'a pas de problemes de texte en japonais mixé au milieu de texte normal, et c'est pourquoi on peut se limiter a de l'ascii.
 
Mais ca ne justifie pas, et c'etait la le but de mon intervention, de preconiser d'utiliser par defaut dans un cadre general seulement une partie de XML. Il faut au contraire essayer d'exploiter la genericite de XML chaque fois qu'on le peut.
Ainsi, si je devellope un produit, pour l'europe, et qu'un nouveau client asiatique se manifeste, je serait fort content de ne pas avoir a modifier de code pour lui vendre ma solution.
 
A+,

Le W3C vient tres clairement de preciser les choses dans sa nouvelle mouture de Character Model for the World Wide Web 1.0 revisée ce vendredi ( http://www.w3.org/TR/charmod/ )
 

 
et  
 

 
A+,