2009-12-18 8 views
2

Je sais que la syntaxe est valide, mais ma question est de savoir s'il est logiquement valide:Est-ce XML valide?

<parent> 
    <name>John</name> 
    <child>Mary</child> 
    <child>Lucy</child> 
    <child>Hannah</child> 
</parent> 

ou une bonne façon de le faire est la suivante:

<parent> 
    <name>John</name> 
    <child> 
     <name>Mary</name> 
    </child> 
    <child> 
     <name>Lucy</name> 
    </child> 
    <child> 
     <name>Hannah</name> 
    </child> 
</parent> 

Y at-il de documents en ligne qui dit certainement qu'est-ce qui est bien et mal?

+4

Il n'existe aucun document en ligne, ou ailleurs, qui définisse la sémantique de tout document XML aléatoire.Il n'y a pas non plus de "bonne" façon de le faire. Tout dépend des données spécifiques stockées, des exigences d'extensibilité futures, du traitement typique attendu, etc. –

+0

@Pavel, pourquoi n'écrivez-vous pas cela comme une réponse? Je vais certainement le voter. –

Répondre

1

Il est à noter que le terme "valide" a une signification spécifique en XML.

Un document XML est valide si et seulement s'il est conforme à sa DTD ou à son schéma. Fondamentalement, l'univers des chaînes de texte est divisé en deux catégories: celles qui sont bien formées au format XML et celles qui ne le sont pas. L'univers des documents XML bien formés est également divisé en trois catégories: les documents XML valides (conformes à leur DTD/schéma), les documents XML non valides (qui ne le sont pas) et ceux dont la validité ne peut être déterminée (parce qu'ils ne le sont pas). t avoir un DTD/schéma).

En ce qui concerne votre véritable question, vous ne pouvez juger de la conception d'un document XML que sur la base de son adéquation aux fins pour lesquelles il doit être utilisé. Allez-vous le transformer avec XSLT? Interroger avec XPath? Le traiter avec Linq-to-XML? Le traiter avec un lecteur SAX? Désérialiser les données dans les objets? L'éditer dans le Bloc-notes? La valider par rapport à un schéma? Le transporter sur un réseau lent? Toutes ces choses (et il y en a beaucoup d'autres) devraient influencer la conception de votre XML. Il n'y a pas une bonne réponse.

5

Cela dépend de ce que vous allez en faire. La 2ème version est meilleure s'il y a une chance que vous ayez besoin de stocker plus de données sur chaque personne dans le futur.

+1

Donc, vous dites que les deux façons sont valides, mais 2e devrait être préféré? –

+0

Si vos besoins de stockage de données ne vont jamais changer, alors la 1ère option fonctionnera très bien. La deuxième option est plus flexible, donc cela pourrait être mieux puisque vos besoins de données changent presque toujours dans le futur. – David

15

Je préfère ce dernier, car il est clair que c'est le NOM de l'enfant qui est Marie, et non l'ENFANT LUI-MÊME qui est Marie.

Je pense que l'utilisation d'attributs est encore mieux, comme ceci:

<parent name="John"> 
    <child name="Mary" /> 
    <child name="Lucy" /> 
    <child name="Hannah" /> 
</parent> 

parce qu'il montre clairement que le nom est juste une caractéristique de l'entité mère/enfant.

+1

Je préfère ceci, parce que sinon le nom du parent a le même poids logique que leurs enfants. – Skilldrick

+3

+ 1 pour suggérer de rendre le XML moins gonflé :) – OregonGhost

+0

J'ai vu XML analyser dans le passé dans certaines applications pas comme le fait qu'un élément n'a pas de nœud de texte. Ils le considèrent comme non standard (SAP était comme ça, je pense - je ne sais pas si c'est toujours le cas), donc avoir un élément significatif sans nœud de texte peut parfois être considéré comme une balise vide, même s'il a des attributs. Donc, cette solution rend le XML moins gonflé, mais pourrait ne pas convenir à tous les scénarios. – Yishai

2

La seconde est préférable. Cela indique clairement que name est une propriété d'un enfant et n'identifie pas l'enfant lui-même.

penser en termes de classes:

Ce

class Parent { 
    string Name; 
    List<Child> Children; 
} 

class Child { 
    string Name; 
} 

est préférable de

class Parent { 
    string Name; 
    List<string> Children; 
} 

La deuxième option vous donne également la possibilité d'étendre à l'avenir (ajouter un élément d'anniversaire, par exemple).

Le débat plus subjectif est de savoir si d'utiliser des éléments ou des attributs pour les propriétés comme name, etc.

Enfin, ajoutez un élément children avec les child éléments qui y sont contenues.

6

La seconde semble plus logique du point de vue de l'extensibilité. Que se passe-t-il si vous devez ajouter un anniversaire pour un enfant dans le premier? Oui, vous pouvez ajouter un attribut XML, mais vous finirez tôt ou tard par vous bloquer sur l'ajout d'un type complexe ou même d'une énumération basique.

aussi - il peut être préférable de regrouper les éléments enfants sous un seul élément « enfants »:

<parent> 
    <name>John</name> 
    <children> 
     <child> 
     <name>Mary</name> 
     <dob>1970-01-01</dob> 
     </child> 
     <child> 
     <name>Lucy</name> 
     <dob>1971-01-01</dob> 
     </child> 
     <child> 
     <name>Hannah</name> 
     <dob>1974-01-01</dob> 
     </child> 
    <children> 
</parent> 

Encore une chose: vous ne serait probablement pas regrouper les enfants de moins d'un élément parent seul, mais je Je l'ai laissé en ligne avec votre original.

+0

Je ne vais pas vous downvote pour ne pas représenter vos dates au format ISO8602, mais je devrais. –

+0

Je pensais à cela, mais je ne pouvais pas être dérangé. Histoire vraie. –

+0

Edité pour être conforme Robert. ;-) –

1

C'est XML, il n'y a pas de vrai ou de faux. Vos deux réponses sont correctes, cependant ceci est également valable:

<parent> 
    <name>John</name> 
    <children> 
    <child>Mary</child> 
    <child>Lucy</child> 
    <child>Hannah</child> 
    </children> 
</parent> 

De quelle façon devriez-vous choisir? Cela dépend de la tâche. Je ne pense pas que les moyens présentés soient les plus flexibles (et si les enfants ont des enfants?

2

Il n'y a pas de bonne réponse à cette question, bien sûr, mais si l'enfant est plus complexe (ou pourrait devenir plus complexe) qu'une seule chaîne de texte, alors la deuxième option est préférable.

En termes de ce que vous voyez habituellement, généralement dans les deux cas tous les éléments enfants seraient regroupés sous un élément enfant. Dans certains environnements de visualisation, il peut être utile de fermer tous les enfants tandis que les autres éléments conservent le focus.

1

Les deux ont raison. Il n'y a aucune définition sur la façon de structurer votre élément - c'est entièrement à vous!

Certaines personnes tentent de réduire le nombre de nœuds. Et ces gens peut-être créer le fichier XML comme

<parent name="John"> 
    <child name="Mary" /> 
    <child name="Lucy" /> 
    <child name="Hannah" /> 
</parent> 

Mais la moindre idée de XML est que vous devez toujours faire aussi easly que possible de lire et de comprendre, pour beeings humains. Visser les compilateurs, ils vous comprendront toujours XML, alors rendez-le humain lisible!

+0

Un attribut est un nœud dans l'infoset XML. –

2

Je voudrais utiliser une alternative entre Shoko et DanDan ou Wim Hollebrandse:

<parent name="John"> 
    <children> 
    <child name="Mary" /> 
    <child name="Lucy" /> 
    <child name="Hannah" /> 
    </children> 
</parent> 

parce que j'aime « l'ensemble » de l'enfant qui sont en fait des enfants.

1

Il n'existe aucune norme pour mapper des données à un schéma XML. Il y a des pratiques communes, dont l'un est d'utiliser striped XML, élément de façon imbriquée prendre des rôles de type/relation/type/relation en alternance:

<!-- striped style, RDF etc --> 
<person> 
    <name>John</name> 
    <children> 
     <person> 
      <name>Mary</name> 
     </person> 
     <person> 
      <name>Lucy</name> 
     </person> 
     <person> 
      <name>Hannah</name> 
     </person> 
    <children> 
</parent> 

Ceci est très régulier, mais un peu plus bavard.

Il est généralement une mauvaise idée de mettre du texte lisible par l'homme dans les attributs pour économiser l'espace:

<person name="fred"/> 

Comme qui exclut toute utilisation de ruby mark up qui est nécessaire pour certaines formes d'internationalisation, ainsi que d'être plus compliqué à rendre en utilisant CSS. Si vous êtes uniquement concerné par la représentation compacte et le texte ASCII, XML n'est peut-être pas le meilleur format à utiliser.