Discussion :

[viscere]

Bonjour,

Je viens de me mettre à XML et j'ai quelques question.

Lors d'un schéma, je veux réaliser un tableau de valeur, par exemple un tableau de réels.

Dois je faire


De plus j'ai quelques problèmes pour différencier élément et attribut. Vu qu 'on peut typer un élément, je n'ai utilisé que ca dans mon schéma et je n'ai aucun attribut. Quelle est la difference entre les deux et quelle est la meilleur solution.

Je vous remercie.

Laurent

[GrandFather]

Bonjour,

ton premier schéma correspond (grosso modo) à ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
	<xs:element name="Tab_R">
		<xs:complexType>
			<xs:sequence>
				<xs:element name="reels" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>

Le deuxième à celui-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
	<xs:element name="Tab_R">
		<xs:complexType>
			<xs:sequence maxOccurs="unbounded"/>
				<xs:element name="reels"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>

La seule différence tient au fait que la cardinalité est placée sur l'élément dans le premier schéma, et sur la séquence dans le deuxième. Concrètement, dans ce cas précis, cela revient au même : ces deux schémas valideront les mêmes instances XML. La situation serait différente si, dans la même séquence, il y avait un autre élément (nommé par exemble "booléen") qui suivait l'élément "réels" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
	<xs:element name="Tab_R">
		<xs:complexType>
			<xs:sequence>
				<xs:element name="reels" maxOccurs="unbounded"/>
				<xs:element name="booléens" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>

Dans ce schéma, le modèle de contenu de l'élément Tab_R est un nombre indéfini d'éléments "réels" suivis d'un nombre indéfini d'éléments "booléens". Ce qui est différent de ce schéma :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
	<xs:element name="Tab_R">
		<xs:complexType>
			<xs:sequence maxOccurs="unbounded">
				<xs:element name="reels"/>
				<xs:element name="booléens"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>

Là, le modèle de contenu de l'élément Tab_R est un nombre indéfini de paires d'éléments "réels" et d'éléments "booléens".

[viscere]

Nikel! Merci GrandFather. Pour ma deuxieme question t'as une idée?

[GrandFather]

Le choix entre élément ou attribut dépend le plus souvent du "feeling" que de règles formelles. Quelques repères cependant :

- Pour un élément donné, il ne peut pas y avoir deux attributs avec le même nom ; en conséquence le nombre d'occurrences pour un attribut dans un élément va de 0 (l'attribut est absent) à 1 (l'attribut est présent)

- L'ordre d'apparition des attributs d'un élément n'est pas toujours restitué correctement par le parseur XML, contrairement à celui des éléments ; cela a généralement peu d'importance, mais il faut le savoir

Personnellement, j'attribue la sémantique suivante aux attributs que j'utilise : je les vois comme les champs simples (de type élémentaire - chaîne, entier, etc.) d'un objet (l'élément), tandis que les champs "complexes" (de type objet) sont représentés par des éléments fils. Cette sémantique est celle reprise par certaines librairies de mapping XML/Objet.

[viscere]

Ok donc meme si je fais que des éléments et pas d'attributs c une sémantique comme une autre qui n'est pas forcément fausse.

Je te remercie pour ton aide. Bonne fin de journée.

Laurent

[vexa]

Bonjour,

Pour ma part, j'ai lu une façon de modéliser qui opte pour un attribut quand il s'agit d'une méta-information, et élément sinon.
Il y été aussi indiqué que le plus simple était de le faire comme on l'aurait écrit sur papier.

La source ::

XML Data Management: Native XML and XML-Enabled Database Systems
By Akmal B.Chaudhri, Awais Rashid, Roberto Zicari

Publisher : Addison Wesley
Pub Date : March 14, 2003
ISBN : 0-201-84452-4

[viscere]

Bonjour,

j'ai toujours du mal a differencier attributs et éléments je ne peux m'empecher de créer uniquement des éléments. J'ai cependant un deuxieme problème :
j'ai tendance à créer des éléments afin d'éclaircir le schéma général et je ne sais pas si c bon ou pas.

Par exemple j'ai un élément <test> qui sera présent un nombre indéfini de fois. Dans chaque test j'ai une date une heure de test et il me faut la position du soleil.

J'ai donc créer un élément <environnement> qui contient l'élément <date>, <heure> et <pos_solaire>

<environnement>
<date/>
<heure/>
<pos_sol/>
</environnement>


J'ai fait ca de nombreuse fois pour d'autre cas. Est ce bien ou pas?

Lors du "parsage" (je compte utiliser castor pour java), je ne vais pas me retrouver avec une multitude de classe java inutiles??

[vexa]

Bonsoir,

J'aurais une tendance naturelle à dire que "ce qui ne sert pas est inutile".

Pas besoin de remerciement pour cette belle Lapalissade, je m'explique.

Si ta structure est la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
<test>
 <environnement>
  <date/>
  <heure/>
  <pos_sol/>
 </environnement>
</test>

On est d'accord que l'élément environnement n'apporte aucune indication utile de structure et alourdi le tout.

Si ta structure est la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<test>
 <autreInfo/>
 <autreInfo2>
   <bla/>
   <bla2/>
   <bla3/>
 </autreInfo2>
 <environnement>
  <date/>
  <heure/>
  <pos_sol/>
 </environnement>
</test>

On peut considérer que environnement apporte une indication pertinente et donc à bien sa place ici.

Ensuite, je vais pondérer cette réponse par les points suivant :

- je suis un jeune BTS, donc je n'ai pas le niveau d'expertise je pense pour pouvoir t'apporter la meilleure réponse possible en matière de structuration, je m'appuie sur les documentations qui ne sont pas légions dans ce domaine,( et qui ne donnent pas de méthodes, juste des points de vue éclairés) et surtout sur ce que le bon sens me dicte en fait.

- je m'autoforme sur XML, et la question que tu te poses, elle représente mes angoisses quotidiennes, à savoir "cette structure est-elle pertinente dans le contexte dans lequel je me trouve et peut-elle répondre aux besoins vers lesquels le système qui s'appuie dessus peut évoluer ?"


Pour finir, tu entends quoi par éclaircir le schéma ?

La façon dont je l'ai compris me pousse à te répondre que c'est le rôle de la documentation, pas du schéma lui-même, parce que le schéma reflète ton choix, pas la raison de ton choix.

@+

Xavier

[viscere]

Merci pour ton analyse vexa! Désolé d'avoir fait ressurgir tes pires angoisses...!

[vexa]

Bonsoir,

T'inquiète, ça m'angoisse justement parce que je me sens pas compétent là dedans, et que c'est un domaine porteur.

A force de m'acharner, quand je maitriserais un peu plus, on sera pote la structuration et moi.

@+

Xavier