[Modelisation] Question générale : Collections [Résolu]

[toopac]

Bonjour,

J'ai une petite question, pas du tout critique, mais qui me trotte depuis quelques temps concernant les listes/tableaux/collections en XML.

mieux vaut-il écrire ceci

Code :

1
2
3
4
5
6
7
8
9
10
11
<Pays>
   <Nom/>
   <Villes>
      <Ville>
         <Nom/>
      </Ville>
      <Ville>
         <Nom/>
      </Ville>
   </Villes>
</Pays>

ou cela

Code :

1
2
3
4
5
6
7
8
9
<Pays>
   <Nom/>
   <Ville>
      <Nom/>
   </Ville>
   <Ville>
      <Nom/>
   </Ville>
</Pays>

?
L'inconvénient que je vois du premier XML est qu'il est plus long, mais l'avantage c'est que si j'ai une liste/collection/tableau vide, j'aurai toujours le nœud <Villes/>
Y a-t-il une règle/convention à ce sujet? Merci.

[Loceka]

Ce n'est que mon avis mais je serais plutôt pour la première même si la seconde n'est pas sémantiquement incorrecte.

Par contre le "nom" je le mettrais plutôt en attribut.

[thelvin]

Goûts et couleurs... À part un ptit chouilla plus long pour écrire les chemins, je ne vois pas de défaut à la première méthode. Par contre elle a l'avantage (rarement utile, mais parfois utile,) de faire la différence entre "aucune ville" et "l'information sur les villes n'est pas incluse."

Donc il y aurait un léger plus pour la première méthode... Personnellement elle ne me vient pas en tête tout de suite quand je me retrouve dans cette situation.

[toopac]

Merci pour vos réponses.

Donc pas vraiment de règle/convention, mais plus un choix personnel si j'ai bien compris?

Donc je vais rester sur la première méthode alors.

Merci encore.

[BiM]

Bonjour,

A noter que certains parseurs préfèrent avoir la liste englobée dans un élément propre comme le premier cas.

[Erwy]

Envoyé par thelvin

Donc il y aurait un léger plus pour la première méthode... Personnellement elle ne me vient pas en tête tout de suite quand je me retrouve dans cette situation.

D'accord avec toi sur tout avec une légère différence.
C'est toujours la première qui me vient en tête mais je me pose toujours l'intérêt par rapport à la seconde (qui gagne souvent ces derniers temps )

Envoyé par BiM

Bonjour,

A noter que certains parseurs préfèrent avoir la liste englobée dans un élément propre comme le premier cas.

Là je pense qu'il y a un abus de vocabulaire .
Que certains outils "évolué" de traitement préfèrent la première méthode c'est possible.Ne les utilisant pas, je n'ai pas de pratique la dessus.
Par contre les parseurs eux s'en tapent le coquillard avec une nageoire de cachalot adulte

[BiM]

Hum, non je parle bien d'outils de parsing (donc des parseurs), je pense notamment à certains parseurs Java comme JAXB (enfin je sais plus si c'est celui là ou un autre qui m'avait causé quelques soucis avec les listes non imbriquées) quand on veut passer de XML à Java directement ou inversement.

[Erwy]

Sauf que ce que tu fais n'est pas du parsing mais de la Serialization et le problème n'est pas sur le parseur XML (qui s'en tape...mais je vais me répéter ) mais sur la partie en aval quand tu es dans du XML > Objet voir en amont sur du Objet>XML.

Le parseur ne fait que lire le XML voir le valide.
Les autres opérations, même si elles peuvent être vendues sous le même emballage sont séparées.

Pour donner un exemple, sur SAXON ou Xercès, quand on parle XSLT, on parle du processeur XSLT et non du parseur XSLT alors les deux fournissent bien aussi un parseur validant

[BiM]

Au temps pour moi

C'est la chaleur, ça tape sur le système

[Erwy]

Ta confusion n'a rien de surprenante

Au premiers temps ces bibliothèques ne contenait que le parseur ou presque, donc un abus de langage est né et on a commencé à parler de parseur Xalan , xerces, Saxon. Mais avec le temps et en particulier récemment on a rajouté tout un tas d'outils du processeur XSLT ou XQuery au sérialiseur. En plus comme toutes ces Api sont belle et bien cliente du parseur cela ne simplifie pas la compréhension de la chose