XSD:contrainte d'integrité selector vs field

[win_ubuntu]

Bonjour,
j'aimerais savoir la différence entre l'élément selector et field.
pour moi un seul élément suffit pour définir la contrainte d'integrité (d'unicité ou reference).
exemple:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<xs:element name="service">
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:element name="employe">
<xs:complexType>
<xs:attribute name="nom" type="xs:string"/>
<xs:attribute name="id" type="xs:token"/>
<xs:attribute name="chef" type="xs:token"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:key name="kid">
<xs:selector xpath="employe"/>
<xs:field xpath="@id"/></xs:key>
<xs:keyref name="chef" refer="kid">
<xs:selector xpath="employe"/>
<xs:field xpath="@chef"/></xs:keyref>
</xs:element>

on peut ,par exemple, utiliser seulement l'élément field pour définir la contrainte d'intégrité:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<xs:element name="service">
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:element name="employe">
<xs:complexType>
<xs:attribute name="nom" type="xs:string"/>
<xs:attribute name="id" type="xs:token"/>
<xs:attribute name="chef" type="xs:token"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:key name="kid">
<xs:field xpath="employe/@id"/></xs:key>
<xs:keyref name="chef" refer="kid">
<xs:field xpath="employe/@chef"/></xs:keyref>
</xs:element>

merci d'avance

[tsuji]

pour moi un seul élément suffit pour définir la contrainte d'integrité (d'unicité ou reference).

Vous voulez dire comme une idée abstracte d'après vous-même? ou bien comme quelque chose vérifiée en practique?... je ne crois pas. (voir même ci-dessous.)

<xs:key name="kid">
<xs:field xpath="employe/@id"/></xs:key>

ça ne peut pas être correct pour la raison multiple.

Voici quelques précisions, sans être exhaustives, dans la construction de xs:key comme de xs:keyref:

[1] xs:selector est obligatoire avec les facets comme minOccurs="1" et maxOccurs="1" dans le schema pour le w3c schema. Par contre, xs:field est obligatoire mais pas nécessairement avoir un seul (minOccurs="1" et maxOccurs="unbounded").

[2] xs:selector et xs:field ont une relation séquentiale.

[3] Le @xpath dans xs:selector ne peut pas pointer en un attribut, par contre, le @xpath dans xs:field peut.

Voyez, les précisions ci-desus sont déjà sufficients de montrer la construction conçue par vous ne peut pas être correct; un bon validant parser doit lever des erreurs au temps même de compilation.

[win_ubuntu]

Envoyé par tsuji

Vous voulez dire comme une idée abstracte d'après vous-même? ou bien comme quelque chose vérifiée en practique?... je ne crois pas. (voir même ci-dessous.)


ça ne peut pas être correct pour la raison multiple.

Voici quelques précisions, sans être exhaustives, dans la construction de xs:key comme de xs:keyref:

[1] xs:selector est obligatoire avec les facets comme minOccurs="1" et maxOccurs="1" dans le schema pour le w3c schema. Par contre, xs:field est obligatoire mais pas nécessairement avoir un seul (minOccurs="1" et maxOccurs="unbounded").

[2] xs:selector et xs:field ont une relation séquentiale.

[3] Le @xpath dans xs:selector ne peut pas pointer en un attribut, par contre, le @xpath dans xs:field peut.

Voyez, les précisions ci-desus sont déjà sufficients de montrer la construction conçue par vous ne peut pas être correct; un bon validant parser doit lever des erreurs au temps même de compilation.

toutes ses raisons je les connais mais elles ne convainquent pas du tout. surement, il y'a d'autres raisons...

[tsuji]

toutes ses raisons je les connais mais elles ne convainquent pas du tout.

Très bien. Donc, vous voulez questionner le motif pourquoi les choses telle quelle sont plutôt que comment faire ceci et cela.^

surement, il y'a d'autres raisons...

Surement. Mais je ne suis pas en aucune façon le porte-parole de la commission concernée loin de là, moins un avocat d'un procès d'intention. Sans doute il y a une analogie au dbase d'en faire un élément comme une table (hiérarchisée): un selector or, et d'en faire un texte ou attribut une colonne: un field qui peut être multiple. On se peut imaginer...

Si vous voulez construire une spécification à la vôtre, je ne peux rien à dire que de vous souhaiter bonne chance... et ce n'est pas une question que je répondrais volunteer, voilà.

[thelvin]

Ok, je comprends pas vraiment comment tsuji essaie de l'expliquer.
Mais la différence entre les deux est claire et la raison pour laquelle il y a besoin des deux aussi. En plus c'est expliqué partout où on parle de <xs:key>. J'ai du mal à voir ce qui peut poser un doute.

<xs:select> sert à déterminer un ensemble de "trucs" (éléments, attributs, nœuds textes) sur lesquels on veut appliquer la contrainte d'unicité.
<xs:field> indique qu'est-ce qu'on doit regarder, dans chacun de ces "trucs", et dont la valeur ne doit pas apparaître plus d'une fois dans l'ensemble déterminé par <xs:select>. D'ailleurs, <xs:field> peut apparaître plusieurs fois, au cas où c'est une combinaisons de plusieurs choses, qui doit être unique dans cet ensemble.

Il est clair qu'une contrainte d'unicité requiert au moins ces deux considérations distinctes.

Pour le coup, MSDN indique sans doute l'explication la plus claire.