Discussion :

[vbrabant]

bonjour à tous, j'ai un petit soucis de compréhension des XSD patterns.
En effet, on a un XSD qui utilise des ID et des IDREF. Jusque là, rien de spécial. Maintenant, les ID doivent être du type NCNAME. Et voici la description du pattern pour le NCName

Code xsd :

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

1
2
3
4
5
<xsd:simpleType name="NCName" id="NCName">
 <xsd:restriction base="xsd:Name">
 <xsd:pattern value="[\i-[:]][\c-[:]]*"/>
 </xsd:restriction>
</xsd:simpleType>

Mais ca veut dire quoi c'est \i et \c.
Je suppose que \c veut dire caractère, mais quels genre de caractères (les accents avec, les_ # @ aussi, ou juste les 26 lettres de l'alphabets)
Et quid du \i

Je suppose aussi que -[:] veut dire qu'on exclut les deux-points.

Vincent

[GrandFather]

Salut,

\i -> Tous les caractères pouvant être l'initiale d'un nom tel qu'il est défini dans la spéc XML 1.0, soit toutes les lettres, '_' et ':'.

\c -> Tous les caractères pouvant composer un nom XML (sauf son initiale), c'est à dire tous les caractères désignés par \i, plus les chiffres, '.' et '-'.

Effectivement, la notation -[] permet de faire la soustraction de deux ensembles de caractères, les ':' ne sont donc pas autorisés. \i, \c et -[] sont des extensions W3C aux expressions régulières PERL.

Si on analyse ton pattern, on voit que le type simple dérivé de xsd:Name est en fait un nom (au sens XML) ne comprenant pas de ':'. Or, ce type existe déjà en tant que type prédéfini dans les W3C XML Schemas, et s'appelle... NCName (NonColonized Name) ! Sauf erreur de ma part, je ne vois donc pas l'intérêt d'une telle dérivation.

[EDIT] je viens de comprendre : l'extrait de schéma que tu as donné provient du "schéma des schémas", c'est bien cela ? Dans ce cas, oublie ma dernière remarque.

[vbrabant]

En effet, c'est ça. J'ai donné un extrait du schéma des schémas. Et j'essaye de comprendre ce pattern pour le transposer en Java pour valider les entrées des utilisateurs.

Tes explications m'ont bien aidées.

Quelque part, je dois valider cela avec Java. Donc, il faudrait transposer ce XSD pattern en Java pattern. Ca va être chaud je pense.

On va voir. Je vais encore chercher.

merci.

Vincent

[GrandFather]

Quelque part, je dois valider cela avec Java. Donc, il faudrait transposer ce XSD pattern en Java pattern. Ca va être chaud je pense.

Comme tu dis, ça va être chaud, il va falloir jongler avec les catégories Unicode...

Si tu as la possibilité d'intervenir sur ton XSD, plutôt que d'utiliser des ID et des IDREF qui ne sont là que pour la compatibilité ascendante avec les DTD, pourquoi n'emploierais-tu pas à la place des xsd:key et xsd:keyref ? Ils servent également à l'intégrité référentielle, et n'ont pas les restrictions des ID/IDREF ; les clés peuvent être de n'importe quel type (pas cantonnées aux NCNames), et tu peux avoir des jeux de clés différents dans des sous-arbres distincts de l'instance XML. Un (court) tutoriel sur les key/keyref : http://www.w3.org/TR/xmlschema-0/#quartelyReport