Bonjour,
 
Voilà je débute dans le XML. Je vais me servir d'un fichier XML pour stocker différents paramètres d'un logiciel. J'ai commencé à faire mon fichier au brouillon :
 

 
(bon il y a d'autres données mais c'est cette partie qui m'intéresse).
En relisant mon brouillon je me suis dis qu'il y avait quelque chose qui clochait. "debit", "bits_donnees", "bits_stop", "parite" n'ont pas la même importance hiérarchique que "port". Après réflexion je suis arrivé à deux résultats :
 

 
et
 

 
bref, je reste perplexe et n'arrive pas à me décider sur ce qui est le plus logique. Bon j'avoue, j'ai l'impression de me prendre un peu la tête pour pas grand chose, sachant que comme je l'ai dit mon fichier sert uniquement pour stocker des paramètres d'un logiciel et n'a donc pas besoin d'être valide mais uniquement bien formé. Mais comme je débute j'aimerai acquérir dès maintenant la bonne démarche d'esprit.
Merci d'avance pour vos réponses

c'est completement arbitraire, mais je préfere le 3.
sauf que je mettrais aussi le nom en attribut

je viens de lire ca sur le site de MSDN :

donc si j'ai bien tout compris, la solution la "meilleure" dans mon cas serait l'utilisation d'attributs comme tu le suggérais lorill.

Je vote aussi pour la solution 3, plus compacte et au final plus lisible, tu t'en rendras vite compte avec un gros document. De plus, la solution 3 peut t'éviter des erreurs car les attributs sont plus limités que les éléments.

 
Les structures proposées par BaCkFiRe peuvent être interprétées de deux façons totalement différentes :
 
1) Si les informations servent à configurer une "communication" en disant quel port elle doit utiliser, quel débit, quelle parité, etc... Alors la première solution me semble la meilleure.
 
2) Par contre, si les informations servent à décrire la configuration du port COM1, alors la première solution ne fonctionne pas du tout et les 2 autres ne sont pas satisfaisantes non plus. Dans ce cas, la 3e solution est même la plus mauvaise ! Pour moi, la meilleure solution serait exactement l'inverse de la 3e de BaCkFiRe, c'est a dire :
 

 
A mon avis, il faut essayer de mettre en attributs les informations orientées "identification" ou "critères de sélection" et laisser le "contenu" dans les éléments. Tout simplement parce que certains outils XML, comme le langage XPath utilisé par exemple dans XSLT, proposent des syntaxes simplifiées pour accéder à des données XML quand on les filtre selon leurs attributs.
 
Par exemple, en XPath, pour accéder au débit du port COM1:
 
- En utilisant la structure que j'ai décrite, il suffit d'écrire :
 

 
- Alors que si on utilise la solution 3 de BaCkFiRe, il faut écrire :
 

 
qui peut effectivement être simplifiée en :
 

 
mais qui reste quand même moins lisible et plus lourde que la première expression...
 
 
Donc, pour pouvoir répondre à BaCkFiRe, il faudrait d'abord savoir si son fichier sert à paramétrer une communication ou à paramétrer un port. C'est à dire si COM1 est une donnée de la "communication" à paramétrer ou si COM1 est l'indentifiant du "port" à paramétrer...

Je préfère la 3, avec le nom en attribut aussi

 
Si le but du fichier XML est de configurer une communication, on peut même aller plus loin que la solution 3 de BaCkFiRe et mettre directement :
 

debit, etc. dépends de la valeur de port ou pas ?
 
je veux dire, t'as COM1... mais si demain d'as LPT1 ou USB, est-ce que tu auras les mêmes attributs ?
 
si oui, alor sla dernière structure proposée par addwyn me plait bien.
si non, perso, je ferais :
 

<Parametres>
  <Communication port="COM1">
    <COM1Settings debit="9600" bits_donnees="8" bits_stop="1" parite=""/>
  </Communication>
  <Communication port="USB">
    <USBSettings version="2.0" power_saving="false"/>
  </Communication>
</Parametres>

 
Et même en variante :

<Parametres>
  <Communication>
    <COM1 debit="9600" bits_donnees="8" bits_stop="1" parite=""/>
    <USB version="2.0" power_saving="false"/>
  </Communication>
</Parametres>

=> L'intérêt de la seconde solution c'est que tu peux aisément effectuer un contrôle en XSD ou DTD ou cequetuveuxquivabien
=> Vu que le type de port est énumérable, et sujet à peu de changements, je pense acceptable de déporter la donnée "port" au niveau de la structure, puisqu'elle est énumérable.

Wahou, alors là je pensais pas avoir des réponses aussi intéressantes plus de 3 ans après ma demande
 

J'ai un peu de mal à voir la différence donc tu vas dire si je me trompe : dans le 1er cas le port série est un moyen de communication comme un autre et cela pourrait être, comme le disait MagicBuzz, LPT1 ou USB ou une adresse IP,... chacun ayant des attributs différents. Et dans le 2ème cas, on communique forcément par série (et on a donc toujours les mêmes attributs) et on décrit les paramètres du port. J'ai bon ?
 
En tout cas merci addwyn pour cette réponse détaillée

 
Oui, c'est bien ça. Pour préciser un peu ce que je voulais dire, je me place du point de vue de l'application. Pour elle, le fichier de paramêtre est là pour répondre à certaines questions:
 
Si l'application demande "Je dois établir une communication. De quelle façon dois-je communiquer ?", alors le fichier XML est là pour donner tous les paramètres de la communication y compris le port. C'était mon cas N°1.
 
Si l'application demande: "J'ai besoin de configurer mon port COM1. Quels paramètres dois-je lui appliquer ?", alors le fichier XML est là pour donner les caractéristiques du port COM1. Dans ce cas, "COM1" est la clé de recherche des informations et non une "donnée". C'était mon cas N°2.
 
Pour le contrôle XSD ou DTD, les idées de MagicBuzz sont très intéressantes. Je retirerais juste le chiffre 1 du nom de l'élément COM puisqu'on peut éventuellement avoir COM1, COM2, etc...
 

 
Par contre, si on condidère que les paramêtres d'une communication série peuvent être indépendants du port série utilisé, alors la 1ere variante proposée par MagicBuzz me parait excellente, avec peut-être quelques petites modifs :
 

encore une fois, réponse très intéressante Je garde toutes ces informations au chaud car j'aurai l'occasion prochainement de remettre les mains dans du XML